Most fraud losses now start with a cyber event, yet in many organisations the fraud team and the security operations centre still watch different data, use different case tools and report to different executives. A phished credential, a SIM swap or a compromised supplier mailbox is a security incident at 09:00 and a fraud loss by 09:30, and neither team sees the whole chain. This guide explains why fraud and cyber converge, the operating models that join them (aligned, integrated and fused, including FRAML), which signals to share, how to run joint cases, what privacy and data sharing law allows, and how to measure whether it works. It is written for fraud, financial crime, security and identity leaders in banks, payment firms, fintechs and digital businesses. Detailed controls for individual fraud types are in the linked guides rather than repeated here.
Key takeaways
- The attack chain crosses the org chart. Account takeover, APP fraud, BEC and SIM swap fraud all combine an intrusion or impersonation step with a money movement step, so a team that sees only one half sees it too late.
- Identity is the shared control plane. Identity proofing, authentication, account recovery and the help desk are where both fraud and intrusion succeed or fail, which makes the identity team the natural bridge.
- Share signals before you merge teams. A short list of high-value signals (credential compromise, SIM swap, new device plus payee change, mule account indicators) exchanged in near real time delivers most of the benefit of a fusion centre.
- Regulation now prices the gap. UK mandatory APP reimbursement, the FCA Consumer Duty, FinCEN advisories and the incoming EU Payment Services Regulation all make undetected cyber-enabled fraud a direct cost or conduct issue.
- Privacy law shapes the design, it does not prevent it. Lawful basis, DPIAs, purpose limitation and statutory gateways such as FinCEN 314(b) and section 188 of the UK Economic Crime and Corporate Transparency Act 2023 define what can be shared and with whom.
Why fraud and cyber converge
The scale is large and still growing. UK Finance reported £1.28 billion of payment fraud losses in 2025, including £576.4 million lost to authorised push payment (APP) fraud across 248,070 cases, up 19%. It found that 66% of APP cases started online and 17% through telecoms, the latter accounting for 28% of losses. In the US, the FBI's Internet Crime Complaint Center recorded 859,532 complaints and over $16 billion of reported losses in 2024, a 33% rise.
The common thread is that criminals use cyber techniques to get into a position to steal, and fraud techniques to take the money. MITRE ATT&CK now models the money step itself as T1657 Financial Theft (Impact tactic), citing business email compromise and "pig butchering" investment scams, and models T1451 SIM Card Swap as a mobile initial access technique.
| Scheme | Cyber or identity step | Fraud step | Where it is covered |
|---|---|---|---|
| Account takeover (ATO) | Credential stuffing, infostealer logs, AiTM phishing, recovery abuse | Payee added, funds moved, loyalty or stored value drained | Account Takeover Prevention Guide |
| APP fraud | Spoofed numbers, impersonation of bank or police, compromised email thread | Victim authorises a push payment to a mule account | Authorised Push Payment (APP) Fraud Guide |
| Business email compromise (BEC) | Mailbox compromise, lookalike domains, abused sending infrastructure | Changed supplier bank details, urgent CEO payment request | Email Identity and BEC Guide |
| SIM swap (T1451) | Social engineering or bribery of carrier staff to port a number | SMS one-time passcodes intercepted, account reset, payment made | Vishing and Smishing Guide |
| Synthetic identity | Fabricated or blended identity data, deepfake documents and selfies | Credit built up then "bust out", or account used as a mule | Identity Fraud Prevention Guide |
| Insider-enabled fraud | Bribed staff or contractors export customer data or change account details | Targeted impersonation scams against the exposed customers | Insider Threat Programme Guide |
| Card-not-present and bot fraud | Card testing bots, scraped or breached card data | Unauthorised purchases, chargebacks | Payment Fraud Guide and Bot Management Guide |
Deepfakes collapse the remaining distance. FinCEN's alert FIN-2024-Alert004 (13 November 2024) describes criminals using generative AI to create fraudulent identity documents and synthetic identities, opening accounts that are then used as funnel accounts for scams. The Arup deepfake fraud showed the corporate version: a video call with a fake CFO led to HK$200 million in transfers, through people and process rather than a technical exploit. See the Deepfake and AI Impersonation Guide.
Operating models: aligned, integrated or fused
There is no single correct structure. What matters is that signals, decisions and accountability meet before money leaves.
| Model | How it works | Suits | Trade-offs |
|---|---|---|---|
| Aligned | Separate teams and tools; agreed signal feeds, a joint playbook set and a monthly risk forum | Smaller firms, or a first step in any firm | Cheap and fast; depends on goodwill; hand-offs still add delay |
| Integrated | Shared data platform or detection layer, joint case queue for cross-domain cases, named liaison analysts in each team | Mid-size banks, payment firms, large e-commerce | Needs data engineering and a common case schema; reporting lines unchanged |
| Fusion centre | Fraud, cyber threat intelligence, AML and sometimes physical security in one operations function under one leader | Large banks and payment schemes with high attack volume | Fastest decisions; organisational change is hard, and specialist depth can be diluted |
| FRAML | Fraud and anti-money laundering combined, sharing customer risk, transaction monitoring and SAR workflows | Firms where mule activity and fraud proceeds dominate | Strong on money flows; can still leave the SOC outside unless cyber is added |
Whatever the structure, give one named executive ownership of cyber-enabled fraud losses, so that neither the CISO nor the head of fraud can treat them as the other's problem. Fusion should join decisions, not turn malware analysts and dispute handlers into generalists.
Shared signals: what each side should send
Most value comes from a small set of signals that one team sees first and the other can act on. NIST SP 800-63A-4 (section 3.2) now requires identity service providers to run a fraud management programme and to communicate suspected and confirmed fraud to relying parties, and recommends real-time shared signalling, SIM swap detection, device and account tenure checks, device fingerprinting and velocity checks.
| Signal | Usually seen first by | Action for the other team |
|---|---|---|
| Customer or staff credentials in a breach corpus or infostealer log | Cyber threat intelligence | Fraud: force reset, step up next payment, watch for new payees |
| Recent SIM swap or number port on the registered phone | Fraud (carrier data feed) | Identity: suspend SMS OTP and recovery for that account |
| New device, new payee and high-value payment in one session | Fraud | SOC: check for malware, remote access tools or session hijack |
| Help desk reset followed by MFA re-registration | Identity or service desk | Fraud and SOC: hold sensitive changes, verify by callback |
| Lookalike domains and phishing kits targeting the brand | SOC or brand protection | Fraud: warn customers, raise scoring for traffic from those campaigns |
| Mule account indicators (rapid in and out, many unrelated senders) | Fraud or AML | Cyber: check whether the account was opened with stolen or synthetic identity data |
| Compromised supplier mailbox or changed bank details request | SOC or accounts payable | Payments: freeze changes to that supplier pending out-of-band verification |
| Leaked API keys or abused sending infrastructure | SOC or cloud security | Fraud: expect phishing or BEC volume from that source |
For identity events there is now a standard transport. The OpenID Foundation's Shared Signals Framework carries security event tokens between transmitters and receivers, with two profiles: CAEP (session revoked, credential change, assurance level change, device compliance change) and RISC (credential compromise, account disabled or enabled, identifier changed or recycled, recovery activated). RISC was designed precisely because attackers target the same person's accounts across several providers.
Joint case management and response
A joint case model needs four things.
- A common case key: link fraud cases, SOC incidents and AML alerts through customer ID, account, device ID and IP address, so an analyst in either tool can see related activity.
- Cross-domain playbooks: write joint runbooks for the scenarios that cross teams, for example a credential dump containing customer accounts, a SIM swap spike from one carrier, a supplier bank detail change, a help desk social engineering attempt and a deepfake executive call.
- Clear decision rights: agree in advance who may block a payment, freeze an account, revoke sessions or contact a customer, so nobody waits for approval mid-attack.
- Regulatory reporting from one record: FinCEN advisory FIN-2016-A005 encourages institutions to "internally share relevant information from across the organization" and to include cyber indicators such as IP addresses with timestamps, device identifiers and virtual wallet information in suspicious activity reports (SARs). It also states that a SAR is mandatory where a cyber-event is intended to conduct, facilitate or affect a suspicious transaction of $5,000 or more. For deepfake cases FinCEN asks filers to use the key term "FIN-2024-DEEPFAKEFRAUD".
Feed confirmed outcomes back into fraud models and SOC detections. See the Incident Response Guide and the SOAR and Security Automation Guide.
Data sharing and privacy limits
- Internal sharing (UK and EU): fraud prevention is commonly processed under legitimate interests (UK GDPR Art. 6(1)(f)). Large-scale profiling of customers across security and transaction data is a typical trigger for a DPIA under Art. 35. Record which signals are shared, for what purpose, and for how long they are kept. See the DPIA Guide: Running a Data Protection Impact Assessment.
- Identity providers: NIST SP 800-63A-4 requires a privacy risk assessment of fraud checks before they are implemented, which is a useful discipline outside the US federal context too.
- US inter-firm sharing: section 314(b) of the USA PATRIOT Act (31 CFR 1010.540) gives registered financial institutions and associations a safe harbour from liability when sharing information to identify and report possible money laundering or terrorist activity, which FinCEN says may include information about fraud and other specified unlawful activities. FIN-2016-A005 confirms that 314(b) covers cyber-related information. Registration is through the FinCEN portal and must be renewed.
- UK inter-firm sharing: section 188 of the Economic Crime and Corporate Transparency Act 2023 removes civil liability for breach of confidence when regulated-sector firms disclose information to each other to prevent, detect or investigate economic crime, under a request or warning condition. Section 188(11) is explicit that it does not authorise disclosures that contravene data protection legislation.
- Telecoms and platforms: carrier SIM swap data and platform takedown cooperation usually need contracts or industry schemes, not ad hoc requests. Minimise data: a "SIM changed in last N days" flag is often enough.
Regulatory drivers
| Driver | What it requires or signals | Why it pushes convergence |
|---|---|---|
| UK PSR APP reimbursement (PS23/3, PS23/4) | Since 7 October 2024, sending firms reimburse APP fraud victims on Faster Payments and CHAPS up to £85,000, usually within five business days, with cost split 50:50 between sending and receiving firms; optional £100 excess (not for vulnerable consumers) | Receiving firms now pay for mule accounts they host, so account opening and mule detection become loss lines |
| FCA Consumer Duty (PS22/9) | In force 31 July 2023 for open products and 31 July 2024 for closed products; four outcomes; cross-cutting rule to avoid causing foreseeable harm | Fraud that a firm could foresee from its own security data is a conduct risk, not only a loss |
| FinCEN advisories and alerts | FIN-2016-A005 on cyber-events and cyber-enabled crime; FIN-2024-Alert004 on deepfake media, with red flags and SAR key terms | Expect cyber indicators in SARs and internal sharing between cyber and BSA/AML teams |
| EU PSD3 and Payment Services Regulation | Provisional deal in November 2025: payee name and identifier match check, refunds where a fraudster impersonates the provider's staff (if reported to police and the provider), platforms reimbursing providers when they fail to remove notified fraudulent content, and receiving providers freezing suspicious transactions. Final compromise texts were published on 23 April 2026; we could not confirm Official Journal publication at the time of writing, so check EUR-Lex for status and dates | Spreads liability across banks, telecoms and platforms, which only works with shared signals |
| NIST SP 800-63-4 | Fraud management programme, fraud communication to relying parties and shared signalling for identity providers | Puts fraud controls inside identity assurance, not beside it |
Where identity fits
- Proofing and onboarding: synthetic and deepfake identities enter at account opening. FinCEN's red flags include a customer who declines multi-factor authentication, a suspected webcam plug-in during live checks, and device or geographic data that conflicts with identity documents. See the Identity Verification Buyer's Guide.
- Authentication: SMS one-time passcodes make SIM swap a fraud technique. FinCEN recommends phishing-resistant MFA, and the ATT&CK entry for T1451 lists carrier account PINs as a mitigation. See the Passwordless and Passkeys Guide.
- Recovery and the help desk: the weakest link for both customers and staff. The MGM Resorts breach began with a help desk call, and the Meta AI Instagram account takeovers came through an AI support assistant that sent recovery links to attackers. See the Account Recovery and Help Desk Security Guide.
- Non-human identities: fraud campaigns run on stolen machine credentials. In TruffleNet attackers tested stolen AWS keys at scale and abused Amazon SES to send business email compromise messages. Leaked API keys for payment, messaging or KYC services belong on the shared signals list. See the API Key Management Guide.
How to implement
- Map losses to entry points (month 1): take the last 12 months of confirmed fraud cases and tag each with its entry point (phishing, SIM swap, malware, help desk, insider, data breach, none).
- Agree five to eight shared signals (months 1 to 2): start with the table above. Define format, latency target, owner and retention for each, and complete the DPIA.
- Pilot in shadow mode (months 2 to 4): feed the signals into fraud scoring and SOC triage as information only. Measure how many confirmed fraud cases would have scored higher, and how many good customers would have been stepped up.
- Turn on actions by risk tier (months 4 to 6): automate low-friction actions first (step-up authentication, payee cooling-off, session revocation), and keep hard blocks for high-confidence combinations. Keep each rule behind a feature flag so it can be rolled back in minutes if false positives spike.
- Build the joint case link and playbooks (months 4 to 9): common case key, cross-references between case tools, and tested runbooks for the five or six cross-domain scenarios.
- Exercise together (every six months): run a joint tabletop on a combined scenario, such as a deepfake executive call during a ransomware incident, with fraud, SOC, identity, payments and communications in the room.
- Review structure last (year 2): only then decide whether integration or a fusion centre would remove remaining delays.
Decision guidance: small and large firms
- Small firms and fintechs: focus on the signals your fraud, identity verification and payment providers can supply, require them in contracts, and put one person in charge of cyber-enabled fraud. An aligned model is enough.
- Mid-size firms: invest in a shared data layer and a joint case queue before any reorganisation. Liaison analysts in each team, with access to both tools, are the cheapest way to cut hand-off delay.
- Large banks and payment firms: a fusion centre or FRAML function makes sense where attack volume is high and mule networks are large. Govern shared models through the model risk process.
- Where to score: real-time decisions belong in the payment or login flow; the SIEM suits investigation and correlation. See the SIEM Guide.
Detection and measurement
Log signal exchanges, decisions and outcomes so each confirmed case can be traced to the first signal that could have stopped it. Useful metrics:
- Cyber-enabled share of fraud losses: value and count of confirmed fraud with a cyber or identity entry point, trended monthly.
- Signal-to-action time: median minutes from a shared signal (for example credential compromise) to a protective action on the account.
- Prevented loss per signal: value of payments stopped or reversed where a shared signal contributed, alongside UK Finance style "prevented" figures.
- False positive and friction rate: good customers stepped up or blocked per thousand sessions, and complaint volumes, so that Consumer Duty outcomes are not harmed.
- Mule detection rate: share of inbound fraud funds frozen before onward transfer, which matters directly under 50:50 APP reimbursement.
- Joint case cycle time: days from case open to closure for cross-domain cases, and the share with a linked SOC and fraud record.
Framework mapping
| Framework | Relevant items | How convergence supports them |
|---|---|---|
| NIST CSF 2.0 | GV.RR-02, ID.RA-02, DE.AE-02, DE.AE-07, RS.MA-01 | Defined roles across teams; threat intelligence from sharing forums; correlated analysis with contextual (fraud) data; coordinated incident response |
| NIST SP 800-53 Rev. 5 | IA-12, SI-4, AU-6(3), IR-4, PM-16 | Identity proofing; monitoring; correlating audit repositories; incident handling; threat awareness programme |
| ISO/IEC 27001:2022 Annex A | A.5.7, A.5.24 to A.5.26, A.8.16, A.5.34 | Threat intelligence; incident management; monitoring activities; privacy and protection of PII |
| CIS Controls v8.1 | Controls 8, 14, 17 | Audit log management; security awareness (scam and impersonation training); incident response management |
| MITRE ATT&CK | T1657 Financial Theft; T1451 SIM Card Swap (Mobile) | Model the money step and the SIM swap entry point; T1657 lists approving payments outside email (M1018) as a mitigation |
Common failure patterns
- Breach response stops at the perimeter: after a data breach, the SOC closes the incident but nobody tells the fraud team which customers are now targets. After the Coinbase insider breach, in which bribed support agents exposed customer data, the risk shifted to impersonation scams against those customers, which is a fraud problem the SOC alone cannot see.
- Finance processes outside the security model: payment approvals that rely on voice or video recognition, as in the Arup case, need out-of-band verification that security, not just finance, has designed.
- SMS as the last line: fraud controls that trust SMS OTP while the SOC knows the brand is targeted by SIM swap and SMS phishing. The Twilio breach showed how SMS phishing of staff opens a path into many downstream organisations.
- Privacy as a veto at the end: a converged model built first and assessed later is often halted. Involve the DPO at the signal design stage.
- Metrics that reward each team separately: SOC measured on incidents closed and fraud on loss rate, with cyber-enabled fraud counted by neither.
Practitioner checklist
- Tag 12 months of fraud cases by cyber or identity entry point to set a baseline.
- Name one executive accountable for cyber-enabled fraud losses.
- Agree five to eight shared signals with owner, format, latency and retention, and complete a DPIA.
- Feed credential compromise, SIM swap and help desk reset events into fraud scoring.
- Link fraud, SOC and AML cases through a common key, and write joint playbooks for five or six cross-domain scenarios.
- Include cyber indicators (IPs with timestamps, device IDs) in SARs where required, and register for 314(b) or use ECCTA s.188 where relevant.
- Replace SMS OTP for high-risk actions with phishing-resistant methods, and harden recovery and help desk processes.
- Track signal-to-action time, prevented loss, mule detection and customer friction monthly.
- Run a joint fraud and cyber tabletop at least twice a year.
Standards and references
- NIST: SP 800-63A-4 Digital Identity Guidelines, Identity Proofing and Enrollment
- FinCEN: Advisory to Financial Institutions on Cyber-Events and Cyber-Enabled Crime (FIN-2016-A005)
- FinCEN: Alert on Fraud Schemes Involving Deepfake Media Targeting Financial Institutions (FIN-2024-Alert004)
- FinCEN: Section 314(b) information sharing
- Payment Systems Regulator: APP fraud reimbursement protections
- UK Legislation: Economic Crime and Corporate Transparency Act 2023, section 188
- OpenID Foundation: Shared Signals Working Group
- MITRE ATT&CK: T1657 Financial Theft
Related NHI Mgmt Group resources: Fraud Prevention Guide for Digital Businesses · Account Takeover Prevention Guide · Authorised Push Payment (APP) Fraud Guide · Payment Fraud Guide · Bot Management Guide