A member's account gets drained on a Tuesday. My side of the house tends to see it first, and we see it as a security event: a burst of failed logins from a residential proxy pool, one success, a new device, a session that behaves nothing like the person it claims to be. We tag it credential stuffing, force a reset, rotate the tokens, close the detection. Clean work. The metric looks good.
Three days later a different team opens a different case about the same account. Their version is a fraud case: an external transfer that cleared, a mule account on the receiving end, a dispute the member filed, a loss the institution eats. Same adversary, same night, same login — a separate ticket in a separate tool owned by a separate org, with no thread connecting the two. One team closed a security incident. The other opened a fraud loss. Nobody closed the loop, because there was no loop to close.
That gap is the subject of this post. Account takeover, synthetic identity, and scams do not respect the line your org chart draws between fraud and security. They live directly on it. And most companies I watch — fintechs and the financial institutions we work with — respond by staffing both sides of that line and quietly forbidding the two sides to share a spine.
Here is the claim I will defend: fraud and security are one threat model wearing two budgets. The adversary is the same, the signal is the same, the tooling does the same job under different names, and the only thing genuinely separate is the reporting line. Run them as two siloed orgs and you hand a single attacker two half-blind defenders. Run them as one threat model and the attacker stops getting to arbitrage the seam between them.
I am not arguing to collapse two teams into one box on Monday. I am arguing that the threat model, the signal, and the case have to be shared even when the boxes are not. Let me walk through where the seam actually sits.
Account takeover is one event, not two tickets
Account takeover is the cleanest illustration, because it is the same attack described twice. From the security side it is intrusion: credential compromise, session hijacking, MFA fatigue and prompt-bombing, a device that should never have been trusted. From the fraud side it is objective: the money movement, the new payee, the velocity, the mule on the other end. These are two halves of one kill chain. The compromise is the entry. The transfer is the goal.
The trouble is that security owns the front half and declares victory at "we reset the password," while fraud owns the back half and starts its clock at "money moved." The minutes between a session going bad and a payment leaving the building are exactly where the loss lives, and they are the one stretch of the attack that neither team fully owns. Credential stuffing is a security detection and a fraud precursor at the same time. Treat it as only the first and you close a ticket on an attack that is still in progress.
The regulators, to their credit, drew this line where I am drawing it. The FFIEC's 2021 guidance on authentication and access to financial institution services treats access risk and transaction risk as a single continuum, not two disciplines — the point at which someone gets in and the point at which they do damage are described as one problem to be managed together. The regulator saw the continuum. The org chart never followed.
The signal is shared; only the pipelines are separate
Here is what makes the separation indefensible rather than merely awkward: both teams derive the same primitives from the same events, in parallel, and then never join them. The security stack watches the login. The fraud stack watches the transfer. Both of them are looking at the same device, the same session, the same person, the same night.
- Device and browser fingerprint. The thing that identifies a machine across sessions is equally a compromise indicator and a fraud indicator. Both teams compute it. Neither shares it.
- Network reputation. IP, ASN, proxy and VPN detection, the residential-proxy pools that launder credential-stuffing traffic — identical inputs to a detection rule and a fraud rule.
- Behavioral and session telemetry. Typing cadence, navigation path, dwell time, transaction velocity. Security calls it anomaly. Fraud calls it a behavioral signal. Same feature vector.
- The identity graph. Which accounts share an email, a phone, a device, a fragment of an SSN. This is the single most valuable object either team owns, and it is usually built twice, badly, in two places.
- Authentication events. Step-ups, resets, MFA challenges, failed factors. Fraud needs these to score a transfer. Security needs these to score an intrusion. One log, two owners.
The failure is not that the signal is missing. It is that security lands it in a SIEM keyed to a host or a user, fraud lands it in a rules engine keyed to an account or a transaction, and there is no common join key between the two schemas. If you joined those streams on device_id and session_id, a device the fraud engine has already seen minting synthetic identities and a device my detections have seen stuffing credentials would resolve to one entity with one story. Instead they resolve to two tickets that never meet. The highest-leverage move here is not a reorg. It is a shared signal layer with a common entity key.
One threat model, two vocabularies
Security describes adversaries in a mature, shared language: MITRE ATT&CK tactics and techniques, kill chains, TTPs, indicators of compromise. Fraud describes the same adversaries in a parallel language of modus operandi, typologies, rules, and case dispositions. There is no widely adopted ATT&CK-equivalent for fraud, which means the two disciplines cannot even compare notes on the same actor without a translation layer nobody has built. You end up with one campaign documented in two taxonomies that do not map to each other.
Look at where the marquee threats actually sit, and they all land on the seam. Synthetic identity is the obvious one. The Federal Reserve's own definition frames it as combining real and fabricated information to create a new identity — which is a fraud typology and an identity-proofing failure at the same instant. The onboarding team calls it application fraud. The identity-assurance team calls it a proofing gap. It is one thing, and it is nobody's undivided responsibility.
Scams sit on the same line from the other direction. Business email compromise is literally an email account compromise — squarely a security incident — that terminates in a wire transfer, squarely a fraud loss; the FBI's IC3 has for years ranked BEC among the costliest categories of reported cybercrime. Imposter and investment scams are the same story aimed at the member instead of the employee: the FTC's Consumer Sentinel data has put imposter scams among the top reported fraud categories, with reported consumer losses running into the billions. And here Regulation E draws a hard, consequential line — an unauthorized electronic transfer carries strong consumer protection, while a transfer the customer was deceived into authorizing largely does not. Which means the exact social-engineering playbook your awareness program fights on the inside is the one draining members on the outside, and only one of those two fronts usually has a team formally assigned to it.
Two teams means the attacker sees one company and you see two
The adversary does not experience your org chart. They run one campaign across one attack surface: probe the auth endpoints, harvest sessions, test a batch of synthetic identities against onboarding, move money where it clears. You respond with two investigations that never reconcile. That asymmetry is not neutral — it is exploitable. The attacker gets to arbitrage the seam: run the security-noisy reconnaissance where only fraud happens to be watching, then execute the money movement where only security holds the session context that would explain it.
The seam runs through the compliance function too, and it is just as split. Suspicious activity reporting under the Bank Secrecy Act lives with fraud and AML. Incident response and the GLBA Safeguards obligations live with security. FinCEN's 314(b) provisions let institutions share information about suspected fraud and money laundering with each other — a tool the fraud side uses and the security side frequently does not know exists. FS-ISAC threat intelligence flows to the security side, and the fraud side is often not plugged into it. Two teams means two intelligence feeds, two vendor stacks, two on-call rotations, and two independently tuned sets of thresholds that a patient attacker can profile one at a time. Everything about the split is legible to the person attacking you.
Build a fusion function, not a merger
The fix is not to redraw the org on a whiteboard and declare fraud a subsidiary of security, or the reverse. The reporting lines can stay exactly where they are. What has to be shared is the spine, and it goes together in a specific order, because the later steps are worthless without the earlier ones.
- Agree on a shared entity model and a single join key. Accounts, devices, sessions, and identities resolve to one graph that both teams write to and read from. Nothing downstream works until this does, so this is where you start and where you refuse to compromise.
- Land both signal streams in one store. SIEM telemetry and fraud-engine features go to a common place, keyed to that entity model, so a device is one row with one history rather than two rows that never learn about each other.
- Link the case, not just the alert. When a security detection and a fraud case touch the same entity inside a time window, they auto-associate into a single investigation with a single timeline. The Tuesday login and the Friday transfer become one record.
- Write one threat model. Maintain a single catalog of adversary behaviors that maps ATT&CK-style techniques to fraud typologies, so both teams are demonstrably describing the same actor and can hand work across the seam without a translation loss.
- Run a joint review on a cadence. The highest-signal account-takeover, synthetic-identity, and scam cases get reviewed by both disciplines in the same room. The convergent pattern only becomes visible when the two halves are physically next to each other looking at one timeline.
Notice what this is and is not. It is a shared signal layer, a shared entity graph, a shared case, and a shared threat model. It is not necessarily a shared boss. I have made the case elsewhere for putting genuinely adversarial mandates under one owner, and sometimes that is right here too — but you do not need to win the org fight to close the seam. You need the two functions to stop maintaining two private copies of the same reality.
Stop running two teams
Pick one entity key and make both systems write it before you argue about anything else. Join your account-takeover detections to your money-movement cases for a single week and count how many were the same event — the number will end the debate faster than any deck. Put security and fraud in the same case review before you touch the org chart. And when you report to the board, report the seam as one risk with one owner accountable for it, not as two comfortable line items that each look managed in isolation.
If you have actually fused a fraud and a security function — shared signal, shared case, shared threat model — I want to hear where it broke first, because the entity-resolution problem is the part everyone underestimates and nobody writes up. Tell me in the comments how you drew the join key, and what you had to give up to get both sides to write it.
