Retail portals, corporate cash-management platforms and card programmes are cloned constantly. The Phishing Detection API gives your fraud, security and channel teams a single authoritative answer to one question: is this domain a live phishing host right now?
The economics are simple: a cloned login page converts directly into money, and the brand does the persuading for free.
A bank is unusual among phishing targets because the credential and the asset sit in the same place. When an attacker clones a retail online-banking portal and a customer types their username, password and one-time code into it, there is no lateral movement to plan and no data to monetise later. The session is the prize.
The directness of the payoff is why the same handful of large retail brands appear in impersonation reporting quarter after quarter, and why industry reporting consistently places financial services among the most impersonated sectors of all. A bank's phishing exposure is not proportional to its security spend; it is proportional to how many people recognise its name.
A single bank might run a retail portal, a mobile app with deep links, a corporate cash-management platform, a trade finance portal, a card-services micro-site, a mortgage application journey, a wealth-management client login and a recruitment site — each on its own hostname, and often each with its own vendor behind it.
Rarely “is this our website?” Almost always “is this one of ours, one of our suppliers', or a clone?” That question has a domain at the centre of it, and it is the only part of the whole problem that can be answered in a few milliseconds by a machine rather than by a person reading a screenshot.
Every one of these is a separate hostname a customer has been taught to trust, and every one can be cloned independently of the others. Which is why an inventory of “our domains” is never the same object as a verdict on “this domain”.
Banking phishing is not one skilled adversary. It is a supply chain with specialists at every stage, and it moves faster than any manual review process a bank can staff.
None of that supply chain survives contact with a list that is rebuilt daily and contains only domains proven to be resolving. The value is not cleverness. It is that the answer arrives before the customer clicks.
Each one ends at a domain your systems could have refused to resolve, and each one lands on a different team inside the bank.
The SOC sees a URL in an inbound message and a proxy log entry. The fraud operations analyst sees a disputed transaction and a customer who insists they were on the bank's website. The head of financial crime sees a mule account opened three weeks ago that is now receiving a scattered pattern of small credits. All three are looking at different points on the same campaign — and in nearly every case a phishing-hosting domain sits in the middle of it.
Retail campaigns are volume plays: send a million SMS messages, convert a fraction of a percent, drain the accounts within the session. Corporate and commercial campaigns are patient and targeted — research the finance function, learn the supplier relationships, wait for a genuine invoice cycle, then change one set of account details. The retail attack wants a password; the corporate attack wants a payment instruction, and will happily spend six weeks earning one.
Invoice and supplier fraud aimed at a bank's corporate clients is operationally the same failure as business email compromise: a payment leaves the bank on an instruction the customer genuinely authorised, having been deceived upstream. That distinction matters enormously for liability and for how the case is handled, but it does not change the control.
In both shapes, the deception is carried by a lookalike domain that a check would have flagged. If your institution also insures against these losses or handles the resulting claims, the same reasoning applies on the insurance industry page.
The archetype. A pixel-accurate copy of the retail online-banking login, served from something like secure-login-verify.example.com, reached from an email about a blocked payment or an expiring security certificate. Modern kits render the full multi-step journey, including the security-image step banks added specifically to prove authenticity.
Harvested credentials are replayed within minutes, often from a residential proxy in the customer's own city so device and geolocation signals in the fraud-scoring engine look unremarkable.
A page that asks for the one-time code, the card reader response or the push-approval confirmation, and relays it into a live session against the genuine platform in real time. The customer sees a plausible "confirming your details" spinner while a payee is added on the other side.
This is the pattern that quietly undermines strong customer authentication as a standalone control: the factor is genuine, the customer really did approve it, and the approval was solicited by a domain nobody checked.
Aimed at the bank's corporate and commercial clients rather than the bank itself. A lookalike of a supplier's domain, differing by one character or a swapped TLD, carries a request to update remittance details before a scheduled payment run. The finance controller acts on it and initiates a legitimate, correctly authenticated transfer to the wrong account.
Because the payment is authorised, it clears every control the payments stack has. The only place it could have been stopped is the domain in the sender address and the reply-to.
Fake recruitment portals, "payment processing agent" job adverts and crypto-arbitrage landing pages that exist to onboard people who will receive and forward stolen funds. They are phishing sites in every technical sense, harvesting identity documents and account details, but the head of financial crime meets them as an account-opening problem rather than a security one.
Checking the domains that appear in customer-supplied "employer" references gives the onboarding team a signal that a KYC document set alone cannot provide.
An SMS about a card block or a delivery fee, a short link, and a landing page that either mimics the mobile app's web view or pushes a sideloaded package. Because the link arrives outside email, the secure email gateway never sees it, and because it is opened on a personal handset, no endpoint agent sees it either.
The domain, however, is the same kind of object as any other, and the contact centre will start hearing about it within an hour of the first send.
Fake merchant checkouts, bogus refund forms and "verify your card to release a held payment" pages that collect the full pan, expiry, security code and billing address. For an issuer this shows up as a cluster of card-not-present authorisations across unrelated merchants that share nothing except the compromised cards' recent history.
Feeding the harvesting domains into the issuer's fraud case management alongside the compromise window turns a scattered set of disputes into one identifiable event.
Six placements cover almost every path a phishing domain can take into or out of a financial institution.
The API is deliberately narrow: send a domain, get back whether it is on a DNS-verified list of live phishing hosts. That narrowness is what makes it easy to place in six or seven different systems without a project. Nothing here requires touching core banking, and nothing requires a change to how SWIFT or CBPR+ messages are processed — the integrations sit at the edges, where domains actually appear.
Extract every hostname from the sender, the reply-to, the display-name spoof candidates and the message body, batch them, and check them before delivery. This is the highest-value placement for a corporate bank, because it catches the supplier-domain lookalikes that carry payment diversion.
Banks that host secure-message inboxes, statements with embedded merchant links, or marketplace integrations are effectively publishing third-party URLs to customers. Checking them at render time means the bank never becomes the delivery mechanism for someone else's campaign.
The placement most often overlooked. A customer rings, reads out a URL from a text message, and the agent needs an answer within the length of that call. A single-field lookup wired into the agent desktop turns a five-minute escalation into a two-second one, and the customer gets the same answer the SOC would give.
When a disputed transaction is opened, automatically check every domain already attached to the case. The analyst then opens a file that already says which of those domains were live phishing hosts, and when each was last confirmed resolving, instead of starting the research from nothing.
A scheduled playbook takes the distinct external domains seen in proxy and DNS logs over the last interval, batches them a hundred at a time, and raises a case for any hit with the source IP already resolved to a workstation or a branch. That is exactly the workflow described on the SIEM integration use case.
The widest blast radius of the six. Export the CSV each morning and push it into a response policy zone on an Infoblox-class resolver, or into a URL category on the next-generation firewall, and every device on the corporate network fails to resolve every domain on the list without any application knowing the API exists. Detail on the daily threat feed page.
The worked example below is the second-most common pattern in practice: three hostnames pulled out of a single inbound message that reached a corporate customer's accounts-payable mailbox, checked in one call.
curl -s -X POST https://phishingdetectionapi.com/api/v1/batch \
-H "Content-Type: application/json" \
-d '{
"apikey": "YOUR_API_KEY",
"domains": [
"secure-portal-verify.example.com",
"cdn-assets-eu.example.net",
"mail.supplier-invoices.example.org"
]
}'
# response
{
"results": [
{ "domain": "secure-portal-verify.example.com",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:11Z" },
{ "domain": "cdn-assets-eu.example.net",
"is_phishing": false, "category": null,
"dns_status": null, "confidence": 0.0,
"last_checked": "2026-07-27T04:30:11Z" },
{ "domain": "mail.supplier-invoices.example.org",
"is_phishing": true, "category": "phishing/malware",
"dns_status": "resolves", "confidence": 0.98,
"last_checked": "2026-07-27T04:30:11Z" }
],
"checked": 3,
"phishing_found": 2,
"credits_used": 3
}
Maximum 100 domains per batch call, one credit per domain. Full field reference on the API documentation page.
phishing_found as a routing key, not a verdictWhen it is zero, the message continues down its normal path and the result is written to the log for later retro-hunting; no human is involved. When it is one or more, four things should happen automatically:
The same pattern generalises to the single-domain endpoint for interactive use. A contact-centre agent tool, a fraud analyst's browser extension and a case-management enrichment hook all want one domain and a fast answer, which is what /api/v1/check is for. Payment institutions and acquirers running a similar stack will find the equivalent walkthrough on the payment processors use case, and digital-first institutions on the fintech use case.
Every domain in the database has been resolved and confirmed to be serving before it is published, and the whole set is rebuilt on a fixed daily cycle.
A realistic weekend run against a retail bank's customers, and where the daily rebuild lands in it.
Forty domains are registered across two cheap registrars in a single session, all variations on the bank's brand plus a security-flavoured word. Nameservers are set but no A records are published. At this point the domains are effectively invisible: they are in registration data, but they resolve to nothing, host nothing and have sent nothing. Any reputation system relying on observed traffic has no signal, and a bank watching for newly registered lookalikes will see the names without being able to say whether they are a campaign or a defensive registration by someone else.
Three of the forty are pointed at a hosting provider, the kit is deployed, and a mixed email and SMS send begins around 22:00 local time, aimed at a customer list from an unrelated breach. The message says a payment has been held for verification. The timing is not incidental: the fraud desk is on an overnight rota, the SOC is at reduced tier-1 staffing, and the bank's own call centre closed hours ago, so the only channel a worried customer has is the link in front of them.
Recipients report the messages, spam traps catch a share of the send, and the URLs propagate through curated threat-intelligence and OSINT collection. This is the point at which the campaign becomes knowable to anyone outside it. The bank's own contact centre logs a rising count of customers describing the same text message, but nobody has yet correlated the three domains into a single event, because each agent handled a separate call.
The ingest pass pulls in the newly reported hosts, each is resolved using fifty concurrent threads through rotating proxies with a ten-second timeout, and the three that are still serving the kit are retained with an active A record. Anything that has already been suspended by the registrar is dropped, which keeps the list to infrastructure that is genuinely live. Deduplication and classification run, the day's changelog is diffed against the previous build, the API is loaded and the CSV feed is exported. From this moment a lookup on any of the three returns is_phishing: true.
The morning feed pull lands the new entries in the resolver's response policy zone and the firewall category, so no device on the corporate estate resolves them. The SEG re-checks quarantined and delivered mail from the last 72 hours and finds the delivered copies. A SOAR playbook replays Friday and Saturday's proxy and DNS logs against the list, producing a list of customers and staff who actually reached the page, which the fraud operations analyst uses to force credential resets and watch-list the affected accounts before Monday's payment cycle. The three domains are now attached to one case rather than nineteen unrelated complaints.
A domain-reputation check contributes evidence to several regimes at once, and satisfies none of them on its own.
Financial institutions carry more overlapping obligations than almost any other sector, and phishing sits awkwardly across them — operational resilience, authentication, data protection, card schemes and, for listed institutions, disclosure. The useful way to think about a domain check is not as a compliance product but as a control that produces evidence: a timestamped record that a specific domain was evaluated against a maintained list at a specific moment, which is what turns an assertion in a control narrative into something an examiner can test.
DORA asks financial entities to manage ICT risk, report significant incidents, test resilience and oversee third-party ICT providers. A maintained, externally sourced threat list feeds all four: it is a documented ICT risk control, it enriches incident classification, it gives resilience testing a concrete detection to exercise, and the provider itself becomes a registered third-party ICT dependency you assess like any other.
PSD2 and its strong customer authentication requirements govern how a payment is authenticated, not how the customer was persuaded to authenticate it — which is precisely the gap real-time OTP relay exploits. A domain check is one of the very few controls that operates upstream of the authentication event rather than inside it.
FFIEC interagency guidance on authentication and access to financial institution services expects layered security and a risk assessment appropriate to the transaction and the channel. Domain reputation is a legitimate layer to name in that assessment, particularly for the channels where authentication alone is known to be insufficient.
PCI DSS v4.0 applies wherever cardholder data is stored, processed or transmitted — for an issuer or acquirer, most of the estate — and v4.0 explicitly added the expectation of mechanisms to detect and protect personnel against phishing. A checked domain list is a straightforward way to evidence that such a mechanism exists and is maintained, alongside the standard's separate expectations around payment-page script integrity, which a domain lookup does not address at all.
GDPR Article 32 requires security measures appropriate to the risk, and Articles 33 and 34 govern breach notification, including the seventy-two hour window for notifying the supervisory authority. When a phishing campaign against customers becomes a personal data breach, the questions asked afterwards are what measures were in place and how quickly the institution understood the scope. Retro-hunting proxy logs against a dated list is one of the faster ways to establish who actually reached the page.
For listed institutions, the SEC cybersecurity disclosure rules require disclosure of material incidents and a description of risk-management processes. A named, documented detection control with a defined refresh cycle is considerably easier to describe in a filing than an ad hoc arrangement assembled during the incident itself.
The table below is deliberately honest about the third column: it lists what a domain-reputation check contributes and what it plainly does not cover. Firms whose exposure runs through professional advisers should also read the legal services page, and card-acquiring relationships are covered on the e-commerce and retail page.
| Obligation or control | What the regime expects | What a domain-reputation check contributes | What it does not cover |
|---|---|---|---|
| DORA | ICT risk management, incident reporting, resilience testing and oversight of third-party ICT providers for financial entities. | A documented detection control with a defined update cycle, plus enrichment that speeds up incident classification and scoping. | Governance, the register of information, threat-led penetration testing, or exit strategies for critical providers. |
| PSD2 / SCA | Strong customer authentication for electronic payments, with dynamic linking for remote transactions. | Intercepts the deception upstream of the authentication event, where relay and signing-page attacks actually operate. | The authentication mechanism itself, exemption management, or anything inside the payment initiation flow. |
| FFIEC guidance | Layered security and periodic risk assessment for authentication and access to financial services. | A nameable layer for the risk assessment, applied consistently across email, web, contact centre and network channels. | Customer authentication design, transaction monitoring rules, or the periodic assessment process itself. |
| PCI DSS v4.0 | Protection of cardholder data, anti-malware and anti-phishing mechanisms, and protection of personnel against phishing. | Evidence that a maintained anti-phishing detection mechanism exists and is applied to the relevant channels. | Payment-page script integrity, network segmentation, key management, or the scope definition of the cardholder data environment. |
| GDPR Art. 32 / 33 | Security measures appropriate to risk, and notification of the supervisory authority within 72 hours of a qualifying breach. | A technical measure to point to, and dated records that let you retro-hunt logs and scope who reached a page. | Lawful basis, data minimisation, DPIAs, the notification decision, or communication to affected data subjects. |
| SEC disclosure rules | Disclosure of material cybersecurity incidents and description of risk-management processes by listed companies. | A concrete, describable detection process, and faster scoping so materiality can be judged on evidence. | The materiality judgement, disclosure controls, board oversight reporting, or filing timelines. |
The six that come up in almost every conversation with a CISO, a head of financial crime or an integration architect.
Credits are bought in pay-as-you-go packs and one credit is one lookup, whether that lookup is a single check or one domain inside a batch. The per-credit price falls with volume: Starter is $59 for 10,000 ($0.0059 each), Professional is $249 for 100,000 ($0.0025), Business is $499 for 250,000 ($0.0020), Enterprise is $999 for 750,000 ($0.0013), Enterprise Plus is $1,997 for 2,000,000 ($0.0010) and Scale is $3,999 for 5,000,000 ($0.0008). Credits are valid for twelve months.
The sizing exercise is easier than it looks because you should be caching. Deduplicate domains before you call: a mid-sized bank's gateway sees enormous message volume but a far smaller set of distinct external hostnames per day, and a short-lived local cache collapses most of the rest. Model on distinct domains per day, not messages per day. Full details are on the pricing page.
Design for it rather than assume it away. The database contains domains sourced from curated threat-intelligence and OSINT feeds, each confirmed to be resolving, and a hit returns a confidence of 0.98 rather than certainty. In a bank the practical answer is to make the consequence proportionate: quarantine and review rather than silently delete, warn-and-proceed rather than hard-block on the customer-facing web channel, and hard-block only in the places where a wrong answer is cheap to reverse, such as the resolver policy zone.
Maintain your own allow-list ahead of the check for the domains you know matter: your own estate, your suppliers, your card schemes and your regulators. Check it first and never call the API for those. That single step removes most of the operational risk and most of the credit spend at the same time.
Most banks end up using both, because they answer different questions. Per-lookup checks are for the moment a specific domain appears in front of a specific decision: a message arriving at the gateway, an agent on a call, a case being enriched. They cost one credit each and return in under 50 milliseconds, which is what makes them usable inline.
The daily feed is for enforcement at places where you cannot make an outbound call per request. Downloading the full CSV or JSON export and loading it into a DNS response policy zone, a firewall category or an internal blocklist service gives you enforcement with no per-query cost and no dependency on network reachability at decision time. The feed subscription starts at $499 per month; see the daily feed page. A common split is feed-for-network, API-for-applications.
The only thing a check transmits is a domain name and your API key. No message content, no customer identifier, no account number, no full URL with its query string and no IP address of the person who received the message. If you are extracting hostnames from an email or a proxy log, strip the path and parameters before you call, and you are sending strictly less than what a public DNS query already reveals.
For institutions whose assessment concludes that no external call is acceptable for a given system, the daily feed removes the question entirely: the data moves in one direction, you hold the list inside your own perimeter, and no query ever leaves. That is frequently the deciding factor for the network-layer integrations. Keys must be used server-side only and never embedded in a mobile app or browser code.
It covers newly registered domains from the point they start resolving and are observed in the source feeds, which is a deliberate design choice rather than a limitation to work around. The verification stage resolves every candidate and keeps only those with an active A record, so a name registered on Thursday and parked appears once it is standing up and serving, not before. That is what makes the list precise enough to enforce on: everything in it is live infrastructure.
The consequence is that this is not a newly-registered-domain watch service and should not be used as one. If your control objective is to spot lookalike registrations of your own brand the day they are filed, that is a registrar-data problem and needs a different source. This product answers whether a domain is a confirmed live phishing host, and it answers it about the whole internet rather than just your brand.
Alongside, not instead of. A secure email gateway does things this product explicitly does not: it parses and scores message content, sandboxes attachments, applies DMARC and impersonation policy, and manages quarantine release. What it typically does not have is a second, independent, DNS-verified opinion on the domains it is looking at, and a bank running one vendor's judgement as its only signal has a single point of failure at the exact moment a campaign is novel.
Adding a domain check as an enrichment step gives you an independent verdict you can compare, and it extends the same list to the channels the gateway never sees: SMS links read out to an agent, links inside your own outbound customer messaging, and DNS traffic from devices with no mail client at all. The integration shape is described on the email security use case, and the wider banking view on the banking and finance use case.
Register for an API key and run your last 24 hours of proxy or gateway domains through a batch call. If the list is doing its job, you will find out before your customers do.
