Cybersecurity, Identity & Fraud
Brand Impersonation Detection API
Someone registers a domain one character away from yours, copies your login page, and starts emailing your customers. You usually find out when one of them calls support.
- Brand protection vendors
- Banks
- Consumer platforms
- Marketing and legal teams
- Managed security providers
What your customers would see
example interfaceMockupIllustrative mockup of the interface we would build. Figures shown are examples, not results from a live deployment.
The problem this solves
Impersonation is cheap. A domain costs a few units of currency, a certificate costs nothing, and a convincing copy of a login page is a single save-as away. The same applies on social platforms and app stores, where an account using a brand's name and logo takes minutes to create and often outranks the real one in search for a while.
Detection is a coverage problem before it is a modelling problem. Nobody can watch the whole internet, but you can watch the places impersonation actually appears: newly issued certificates, new domain registrations, social platform handles, app store listings and search results for your own brand terms. Generating the candidate set is mechanical — permutations, homoglyph substitutions, keyword combinations — and the hard part is deciding which of several thousand candidates is worth a human looking at.
What follows detection is usually the bigger operational problem. A confirmed lookalike needs evidence assembled in the form the registrar, platform or hosting provider will accept, and that format differs by provider and changes without notice. An API that finds impersonation but produces evidence nobody can file is only half a product.
Who buys this
Brand protection vendors, Banks, Consumer platforms, Marketing and legal teams, Managed security providers
What the API returns
What comes back
- Lookalike domain detection across typo, homoglyph, keyword and TLD variations
- Content similarity assessment comparing a suspect page to the genuine one
- Logo and visual asset matching via perceptual hashing of rendered pages
- Fake social account and app listing detection using brand name and mark matching
- Monitoring state per candidate: parked, active, mail-configured, or serving a copied page
- Evidence packages formatted for registrar, platform and hosting-provider abuse processes
- Priority ranking, because a parked typo domain and a live credential harvester are not the same problem
- Historical tracking so a repeat offender's pattern across registrations is visible
Endpoints
| Method | Path | Returns |
|---|---|---|
| POST | /v1/brands | Register a brand with its domains, marks and reference assets |
| GET | /v1/brands/{id}/candidates | Current impersonation candidates with priority and state |
| GET | /v1/candidates/{id} | Full evidence for one candidate including captures and similarity |
| POST | /v1/candidates/{id}/triage | Record a confirm, dismiss or escalate decision |
| GET | /v1/candidates/{id}/evidence-package | Takedown-ready evidence for a named provider |
| WS | /v1/stream | Push newly-detected candidates above a priority threshold |
Request and response
illustrativeRequest
{
"brand_id": "brd_examplebank",
"brand": {
"name": "Example Bank",
"owned_domains": ["examplebank.com", "examplebank.co.uk"],
"marks": ["Example Bank", "ExampleBank", "EB Online"],
"reference_assets": ["logo_primary.png", "login_page_capture.png"]
},
"channels": ["domains", "social", "app_stores"],
"min_priority": 50
}Response
{
"brand_id": "brd_examplebank",
"generated_at": "2026-10-21T15:38:20Z",
"candidates_total": 1842,
"above_threshold": 37,
"candidates": [
{
"id": "cnd_90114",
"channel": "domain",
"identifier": "exampIebank.com",
"variation": "homoglyph_capital_i_for_l",
"priority": 96,
"state": "serving_copied_page",
"first_seen": "2026-10-20T09:14:00Z",
"similarity": { "content": 0.94, "logo_phash": 0.97, "layout": 0.91 },
"signals": ["login_form_present", "mx_records_configured",
"certificate_issued_2026-10-20"],
"hosting": { "asn_name": "Example Hosting", "country": "RO" },
"evidence_package_available": true
},
{
"id": "cnd_90118",
"channel": "social",
"identifier": "@examplebank_support",
"priority": 78,
"state": "active_account",
"first_seen": "2026-10-18T13:02:00Z",
"similarity": { "logo_phash": 0.95, "bio_mark_match": true },
"signals": ["replying_to_brand_mentions", "links_to_offsite_form"]
},
{
"id": "cnd_89770",
"channel": "domain",
"identifier": "examplebank.app",
"priority": 22,
"state": "parked",
"signals": ["registrar_parking_page", "no_mx"]
}
]
}Where the data comes from
| Certificate transparency logs | Public issuance logs, usually the earliest notice that a lookalike hostname has been set up |
| New domain registration feeds | Zone and registration data, licensed where the provider requires it |
| Social platform public interfaces | Official APIs and public pages only, within each platform's terms — which vary considerably and restrict automated collection differently |
| App store listings | Published store metadata via official interfaces where available |
| Brand reference assets | Logos, page captures and marks supplied by the brand owner — the comparison baseline |
| Your own abuse reports | Customer-reported impersonation, which both confirms detections and reveals channels the generator missed |
The intelligence layer
The difference between a demo and a service is mostly in this section. These are the parts that keep the answer trustworthy once real traffic is hitting it.
- Candidate generation from typo, homoglyph, keyboard-adjacency, keyword-combination and TLD-expansion rules, scored and filtered rather than dumped on a reviewer
- Homoglyph normalisation across Unicode confusables, since visually identical hostnames in different scripts are a routine technique
- Perceptual hashing of rendered page screenshots and logo assets, which survives recompression and minor edits in a way byte comparison does not
- Content and layout similarity measured on structure as well as text, so a translated copy still matches
- State classification per candidate — parked, mail-configured, serving content — because that drives priority far more than name similarity does
- Page capture from an isolated sandbox that records what it saw with a timestamp and hash, which is what makes the evidence usable later
- Evidence formatting per provider, maintained against their published abuse requirements, which change without notice and need an owner
- Triage feedback to suppress recurring benign matches, such as a partner, a reseller or the brand's own unrecorded property
What it changes for the business
Early detection
Certificate issuance and registration feeds give notice in hours, usually before any customer has been targeted.
Reviewer time focused
State-based priority means a human looks at live harvesting pages rather than a thousand parked typos.
Faster takedowns
Provider-formatted evidence removes the main cause of rejected or stalled abuse reports.
Pattern visibility
Historical tracking exposes repeat registrants, which changes how a legal team approaches them.
How it fits into your product
How it embeds
- Per-brand registration with marks and reference assets, suitable for multi-tenant use by an agency or MSP
- Candidate queue delivered into your existing review tooling with evidence attached
- Webhooks and WebSocket for high-priority detections so urgent cases do not wait for a daily digest
- Evidence package endpoint producing the format a named registrar or platform expects
- White-label reporting for client-facing brand protection summaries
- Triage feedback so each tenant's benign-match suppressions are learned separately
Included in every build
- Authentication, scoped API keys and per-customer rate limiting
- Input validation with predictable, documented error responses
- Versioned endpoints so your integration never breaks without notice
- Request and response logging for audit and dispute resolution
- Latency, error-rate and usage monitoring with alerting
- OpenAPI specification, sandbox environment and client examples
- Backups, failover design and a documented recovery procedure
- An agreed support arrangement once the service is live
How we would build it
about 12 weeksDiscovery and data review
Weeks 1–2
We agree the exact question the API answers, review the sources you already hold, check what has to be licensed, and write down the response contract your developers will code against.
Architecture and prototype
Weeks 3–4
You get a written architecture plus a working endpoint on real data — narrow, but genuinely callable — so integration can be tested against something concrete rather than a document.
Production build
Weeks 5–10
Pipelines, models, storage, authentication, rate limiting, logging, tests and documentation. Security and observability are part of this phase, not a later one.
Integration and handover
Weeks 11–12
We support your engineers through their integration, run load tests at your expected volume, and agree how the service is monitored and supported once it is live.
Commercial models
There is no fixed price list, because the cost is driven by data complexity, integration count, model requirements, request volume and the support level you need. Scope is agreed in writing before development starts.
Fixed-scope prototype
A defined slice of the service, built and priced as one piece of work. The usual first step when the business case needs proving internally.
Fixed-price build
An agreed scope against a written architecture, delivered for an agreed price. Best when the requirements are already clear.
Build then retainer
We build the service, then operate and improve it under a monthly agreement covering monitoring, updates and model maintenance.
White-label product
The service runs under your brand, your domain and your pricing, with MLPivot invisible to your customers.
Questions buyers ask
Can you take the impersonating site down?
No. Takedown runs through registrars, hosting providers, platforms and sometimes courts, and it needs a party with standing — the brand owner or their counsel. What we build assembles the evidence in the shape each provider asks for and tracks the case state. The filing and the follow-up are yours or your client's.
How complete is the social platform coverage?
Uneven, and it depends on each platform's terms rather than on our engineering. Some provide official search interfaces suitable for this; others restrict automated collection sharply or not at all, and a few change position without warning. We scope which platforms are covered during discovery, use only official interfaces and public pages within terms, and would rather state a narrower coverage honestly than imply we watch everywhere.
What is the false positive rate like?
Candidate generation is deliberately broad, so most candidates are not impersonation — parked domains, unrelated businesses with similar names, resellers, and the brand's own forgotten properties. Priority and state classification are what make the queue workable, and triage feedback suppresses recurring benign matches. Expect a few weeks of tuning per brand before the queue settles.
Do you detect impersonation in email itself?
Only indirectly — whether a lookalike domain has mail configured, which is a strong signal of intent. Inspecting message content is a different product and needs access to the mail stream. If that is what you need, it belongs with your email gateway rather than here.
Can we monitor a competitor's brand?
We would build this for a brand owner or their authorised agent, with the marks and assets supplied by whoever holds the rights. Monitoring a third party's brand without that relationship is not something we would scope, and the asset-registration step is where that check sits.
Related blueprints
Phishing URL Detection API
Risk scores and threat classification for any URL or domain, as a check your email gateway, browser or messaging product can run inline.
Domain Security Monitoring API
Continuous passive monitoring of DNS configuration, certificate expiry and externally visible services for domains you are authorised to watch.
IP Reputation Intelligence API
Proxy, hosting, bot and abuse indicators for any IP address, served as a lookup your product can call on every request.
Want this built for your platform?
Tell us what your product does today and what you want another system to be able to ask it. We will come back with an approach, a scope and a price.