Your fraud desk already receives the domains. They arrive in report-phishing mailboxes, in disputed-transaction case notes, in contact-centre call logs and in proxy telemetry from four hundred branches. What is missing is not intelligence — it is a mechanical, sub-50-millisecond answer that every one of those systems can call. This page is a build guide for the four places that answer belongs inside a bank's own operations.
Nothing here is about awareness or vendor selection. It is about the seconds between a domain arriving in a queue and somebody having to decide.
Ask any bank's fraud operations manager what happens when a customer reports a suspicious text message, and the honest answer is a sequence of manual steps. Somebody opens the report. Somebody copies the link out of a screenshot, often retyping it because the image is a photograph of a phone screen taken at an angle. Somebody pastes it into a browser on an isolated machine, or into a public scanning service, or into a group chat where a colleague who is good at this sort of thing takes a look. Ten to forty minutes later there is an opinion, and it is an opinion — not a record, not something the case file can carry, and not something the next analyst who gets an identical report will benefit from.
The reason this persists is not incompetence. The security operations centre has feeds, a SIEM and enrichment playbooks, but the customer report never reaches them; it lands in an operations mailbox owned by the fraud function. The fraud function has case management, transaction monitoring and a rules engine, but none of those systems has any concept of a hostname, because they were built to reason about accounts, amounts, counterparties and devices. The domain is the one artefact common to almost every modern retail fraud case, and it is the only artefact neither system can evaluate.
What closes that gap is a single narrow function — given a hostname, is it currently live phishing infrastructure — exposed as an endpoint that any of the bank's systems can call without a project, a procurement cycle or a data-sharing agreement about customer records. Once that function exists, it can be dropped into a monitoring rule, a triage script, an agent desktop, a template renderer and a resolver policy, and each of those integrations is measured in days rather than quarters. This page is about those integrations specifically, at the level of who owns them and what they change on a Monday morning.
It does not cover the strategic case. If what you need is the sector-level picture — why banks are the most impersonated vertical, what the attack taxonomy looks like, and how the control maps against DORA, PSD2, FFIEC and PCI DSS obligations — that argument lives on the banking and financial services industry page, and it is written for a different reader. What follows assumes you have already decided the control is worth having and now need to know where the wires go.
Everything below treats the lookup as an enrichment. It adds a fact to something your bank already does: a case that already exists, a report already submitted, a notification already being rendered, a DNS query already being resolved. That framing keeps the risk of the integration proportional. A control that only ever adds an attribute cannot break a payment, cannot lock a customer out, and cannot fail in a way that requires an incident bridge at three in the morning.
Four systems, four owners, four completely different latency budgets. Each one can be built independently of the other three.
Monitoring rules reason about amounts, velocity, counterparty history and device fingerprints. They have no vocabulary for hostnames, which means the single most informative artefact in a modern retail fraud case never reaches the model that scores it. The fix is not to teach the rules engine about domains — it is to attach the verdict as a case attribute before an analyst opens the alert, so the domain is already labelled by the time human judgement is applied.
Any hostname already attached to the case — from a customer statement, a referrer, a support note — gets a boolean, a timestamp and a category written alongside it when the case is created.
Do not put this in the authorisation path. Payments must not depend on an outbound call. Enrich when the alert is raised, which is asynchronous and forgiving by design.
A hit is not grounds to auto-decline. It raises the priority of an alert a human was already going to see, and it gives that human a fact rather than a hunch.
Every retail bank runs a report-phishing address, and every one of them is a firehose of near-duplicate reports about the same handful of campaigns. Triage is almost entirely mechanical: extract the hostnames, deduplicate them, check them, and let the analyst spend their attention on the small residue that is genuinely novel. The batch endpoint was built for exactly this shape of work — a hundred hostnames in a single call, one credit per domain.
POST https://phishingdetectionapi.com/api/v1/batch
{ "apikey": "YOUR_API_KEY",
"domains": ["secure-app-verify.example.com", "…up to 100 hostnames"] }
-> { "results": [ … ], "checked": 100,
"phishing_found": 63, "credits_used": 100 }Four hundred reports typically collapse to a few dozen distinct hostnames. Collapse first and the credit cost, the analyst workload and the noise all fall together.
A queue already sorted into confirmed live phishing, not-on-the-list, and unresolved — instead of four hundred undifferentiated forwarded emails.
This is the placement banks think about last and regret first. A bank publishes an enormous number of third-party URLs it did not write: merchant names and links in enriched transaction descriptions, links inside e-documents from partners, servicing notifications generated from templates edited by people outside the security function, and secure-message content forwarded between systems. If any of those resolve to a phishing host, the bank is the delivery mechanism, and the customer's reasonable assumption is that anything inside the banking app was checked.
Merchant logos and links arriving from an enrichment provider are third-party content rendered under your brand. Screen the hostnames on ingest, not on display.
Servicing and marketing templates change often and are edited far from the security function. A nightly batch over every distinct hostname in the template set costs almost nothing.
A statement generated in March may be opened in September. Check when the document is served, and re-check the stored hostname set on a schedule.
Branch estates are the quiet part of a bank's attack surface: thousands of shared workstations, staff who read email between customers, thin local IT presence, and a mail flow full of genuine third-party correspondence that makes lookalike domains hard to spot. This is the one placement where the per-lookup API is the wrong tool. Load the daily CSV export into the resolver policy zone or the firewall category and every device in every branch fails to resolve every domain on the list, with no application changes and no outbound call at decision time.
Pull the rebuilt CSV each morning, diff it against yesterday using the changelog, and push the delta into the policy zone. Enforcement is local and costs nothing per query.
Teller machines have no per-user policy worth relying on and no realistic prospect of a security conversation mid-shift. Network-layer enforcement is the only control that behaves identically for everyone.
Hold the exceptions in one place, applied ahead of the list, so a branch never needs a local override and a removal is one change rather than four hundred.
Not a taxonomy of attacks — a description of the work, and an honest split between the parts this helps with and the parts it does not.
The domain is registered, usually at a reseller that takes payment in an untraceable form and asks for very little else. At this point it resolves nowhere, serves nothing, and appears on no list — including this one. Any control that claims to catch a campaign at this moment is reading registrar data, which is a different product answering a different question.
The name is pointed at a host, a cloned login page is deployed, and the domain starts resolving. That is the moment it becomes eligible for the database, because every entry is confirmed to have a live DNS record before it is published, and the next 24-hour rebuild is what carries it to your resolver and your API calls.
Portal-clone reports arrive in clusters because a single send lands with tens of thousands of customers simultaneously, and the reports that reach the mailbox are a small, self-selecting sample of the people who noticed.
The first hour of a Monday shift in a retail fraud operation is dominated by what accumulated while nobody was working the mailbox. These are the easiest cases for a domain check to improve, because the hostname is right there in the report and forty tickets usually collapse into one campaign the moment you deduplicate.
The measurable change is not detection — it is that the analyst finishes the cluster in twenty minutes instead of two hours and has a domain list to hand to the takedown process.
The takedown request goes to the registrar or the hosting abuse desk against a hostname that has been confirmed as resolving, with the verification timestamp attached. That is materially easier for an abuse team to act on than a forwarded screenshot, and it is the reason the deduplicated domain list is worth producing even when the analyst already knows what the campaign is.
The page comes down, the name stops resolving, and the entry drops out of the next rebuild rather than lingering as dead history. What stays behind is the verdict written into the case file at the time — which is the part that still matters when the loss, the liability and the customer's complaint are reviewed six months later.
The second category lands differently. The customer's account was accessed with a genuine second factor that the customer genuinely approved, having been asked for it by a page nobody checked. By the time this reaches the desk, the money has usually moved, so the value of the lookup is retrospective rather than preventive: knowing that the domain in the customer's browser history was confirmed live phishing at that timestamp turns an ambiguous liability discussion into a documented one. The same evidence trail matters for the claims process described on our insurance page.
These produce the highest report volume and the least usable evidence, because the customer's report is a photograph of a phone. That is worth designing for explicitly: the triage tooling should make it trivial for the analyst to type a hostname into a single field and get an answer, because that is the actual interaction, and the alternative is that they do not check at all. This is also where contact-centre integration pays for itself, since a caller reading a URL aloud is the same interaction wearing different clothes.
This is the shape a domain check helps with least at the fraud desk and most at the gateway. By the time it becomes a case, the payment has been correctly authorised by a real person acting on a deception that occurred weeks earlier. Nothing in a case-management enrichment stops that. What can stop it is checking supplier and reply-to hostnames as messages arrive, which is a mail-flow integration rather than an operations one — see our email security page for that shape.
Mule recruitment is not a fraud case at all when it arrives. It surfaces as an account-opening or account-behaviour question in financial crime, and the domains involved are recruitment portals and payment-agent landing pages. Running the "employer" hostnames a customer supplied during onboarding through a batch call is a cheap, unglamorous check that occasionally lights up an entire cluster of accounts opened in the same fortnight — and it is a check nobody thinks to build because nobody owns it.
One database, one verification standard, one rebuild cycle. The placements differ; the answer does not.
The interface response to a hit is a product decision with a fraud consequence, and it is the part most likely to be got wrong under pressure.
The instinct when a check returns positive on something a customer is about to open is to block it outright. In an internal system that is the right call. In a customer-facing channel it is frequently the wrong one, because a hard block with no explanation produces a support call, and support calls about blocked links are indistinguishable from support calls about broken banking — which means your contact centre absorbs the cost of your security control without being told it exists. Worse, a customer who is blocked without explanation often retries on a personal device outside your estate, which is precisely the outcome you were trying to prevent.
The interstitial that works says three things: this destination is not part of your bank, it has been identified as a site set up to steal login details, and here is what to do instead. It gives the customer an unambiguous way to proceed to their intended task through a route you control, and it gives them a one-click way to report that they received this link, which feeds straight back into the triage queue described earlier. It does not lecture, it does not use the word "phishing" without explaining it, and it does not present a proceed-anyway button as an equal-weight option.
Getting this right requires the fraud, digital product and customer-communications teams in the same conversation, because the wording is a brand artefact as much as a security one. It is also worth agreeing in advance what happens when the verdict is wrong, since it eventually will be. The reasonable posture is warn-and-allow on customer-facing surfaces, hard-block on internal surfaces where a false positive costs one person one minute, and a documented path for a merchant or partner to get a domain reviewed. Publishing that path is what turns an occasional false positive from a complaint into a process.
There is a second, less obvious customer-facing surface: the bank's own outbound messaging. If a servicing email or in-app notification contains a link the bank did not screen, the interstitial cannot help — the customer is already gone. That is the argument for screening at render time as well as at click time, and for holding the stored set of outbound hostnames in one inventory that gets re-checked on a schedule rather than trusting that the template was clean when it was written.
Five operational questions, and the specific field or workflow that answers each one. Where nothing answers it, that is said plainly.
is_phishing — a boolean from a verified list, not an analyst's opinion.dns_status plus last_checked — proof it was resolving, and exactly when.Not features. Latency budget, who acts on a hit, how easily a wrong answer is undone, and what it costs to run.
| Placement | Latency budget | Who acts on a hit | Reversibility | Cost shape |
|---|---|---|---|---|
| Transaction-monitoring enrichment | Seconds — asynchronous, at alert creation | A fraud analyst who was already going to open the case | Total — it is one attribute among many | Distinct domains per case; very low volume |
| Customer-report triage | Minutes — batched, scheduled or on demand | Tier-1 triage, before the queue is worked | Total — nothing customer-facing happens | Up to 100 per call; a few hundred credits a day |
| Outbound link screening | Inline at render — under 50 ms, cached | The renderer, automatically, with a warning interstitial | Partial — warn rather than remove | Distinct third-party hosts per day, heavily cached |
| Branch workstation DNS | None — enforced locally from the loaded list | Nobody; the name simply fails to resolve | Needs a central allowlist entry to undo | Feed subscription; no per-query credit cost |
It is the fastest thing to build, it needs no change to any customer-facing system, and it produces a visible result in the first week: a report backlog that sorts itself into campaigns. It also generates the domain inventory you will want for every other placement, which makes it the natural first step even if the resolver is your eventual target.
Loading the daily feed into a policy zone gives the widest blast radius for the least integration work — every branch, every head-office desk, every VPN client, with no application aware of it. The trade is that undoing a wrong answer requires a central allowlist change, so build that process before you enable enforcement rather than after.
Most institutions end up running both: the daily feed for network enforcement and the API for the application and operations layers. The equivalent split for card acquirers and processors is set out on the payment processors page, and for digital-first institutions on the fintech page.
A known-bad lookup is a floor. Stating the edges precisely is what stops the control being oversold in a steering committee.
It does not catch a domain that has not been verified as resolving yet. Every entry on the list was confirmed to have a live DNS record at the last rebuild, which is what keeps the database free of dead history and makes it safe to enforce at the network layer — but it also means a domain registered this morning and fired into a campaign tonight may not appear until the next cycle. Anyone presenting this control internally should say that plainly, because the alternative is a steering committee that believes it bought prevention and later discovers it bought a very good floor.
It does not help at the moment of payment. When a customer has been socially engineered over six weeks and then correctly authenticates a transfer they genuinely intended to make, no domain check in the payment path changes the outcome. The place a lookup contributes to that class of loss is upstream, in the mail flow where the deception was carried, and afterwards, in the evidence trail that establishes what happened and when. Confusing those two contributions is the most common way this control gets misdescribed.
It says nothing about a phishing page hosted in a directory on a compromised legitimate site. That hostname belongs to a real business, resolves to their real infrastructure, and will still be theirs next month; a domain-membership test cannot express path-level abuse. In practice this is why the network-layer deployment should sit alongside your existing web filtering rather than replacing it, and why the triage workflow needs a route for the residue that the check cannot classify.
The useful logging discipline is to record the domain, the verdict, the last_checked timestamp and the case or message identifier — and nothing about the customer beyond the identifier you already hold. The lookup itself transmits only a hostname and your API key: no account number, no message body, no full URL with its query string, no customer IP. Strip paths and parameters before you call, and the request contains strictly less than an ordinary DNS query for the same name. Retain the verdicts, because they are what makes a case defensible six months later, and resist the temptation to store the raw customer screenshots alongside them. Teams building the surrounding case workflow will find the handling pattern on our incident response page.
Seven questions that come up once the decision has been made and the work is being scoped.
Ownership follows the queue, not the technology. Whoever works the customer-report mailbox owns the triage integration, because they are the ones whose day changes. The SOC owns the network and log-enrichment placements, because they own the resolver and the SIEM.
It should not. Authorisation is a hard-real-time path with a strict latency budget and no tolerance for an external dependency, and adding one to it converts a security enhancement into an availability risk on your most critical flow.
Far fewer than the report volume suggests, because you deduplicate first. A retail bank receiving several thousand customer reports a day typically resolves those to a few hundred distinct hostnames, and a local cache removes most of the repeats within the day.
Every integration described here is designed so that the answer arriving late is acceptable. Triage retries on the next sweep, case enrichment retries when the job runs again, and the resolver placement never makes a call at all because it enforces from a list already loaded locally.
Design the consequence so it is cheap to reverse. Warn rather than block on customer-facing surfaces, hard-block only where a wrong answer costs one internal user one minute, and hold a single central allowlist that is consulted before the list on every placement.
Yes, and it is one of the highest-value placements per hour of engineering. A single field in the agent desktop that takes a hostname and returns a verdict in under 50 milliseconds turns a five-minute hold and an escalation into an answer given while the customer is still speaking.
No — it sits beside them and gives them a second, independent opinion. Your existing gateway parses content, sandboxes attachments and applies impersonation policy; what it usually lacks is a separately sourced, DNS-verified view of the domains it is judging.
Extract the hostnames, deduplicate them, and check a hundred at a time. If the list is doing its job, your triage queue will sort itself into campaigns before an analyst opens it.
