Let Digiqt map your account takeover exposure across digital, recovery, and call centre channels.

Close The Takeover Path, Not Just The Login

# Keeping Real Customers In and Everyone Else Out of Digital Channels

Account takeover is usually discussed as a login problem, which is why so much investment goes into the login page and so many takeovers still succeed. By the time an attacker reaches your authentication screen they generally already hold working credentials, bought or phished, and the interesting question is not how they got in but how they turned access into money.

That journey has several stages, and the controls that stop it are cheapest and most reliable in the middle rather than at the start. Account takeover prevention banking work pays off when it is organised around the whole chain, including the two channels most programmes under-defend: recovery flows and the call centre.

## How does an account takeover actually happen?

Through a chain of five stages, most of which are invisible if you only monitor logins.

| Stage | What the attacker does | Typical defence gap |
|---|---|---|
| Credential sourcing | Buys breach data, phishes, or deploys malware | Happens outside your systems entirely |
| Access | Logs in with valid credentials, sometimes bypassing weak second factors | Controls assume credential validity means legitimacy |
| Reconnaissance | Reviews balances, payees, limits, and statements | Read-only activity is rarely monitored |
| Control change | Changes phone, email, device, or password, disables alerts | Treated as routine self-service |
| Extraction | Moves funds, adds payees, requests cards or credit | Detected at this point, which is too late |

### Which stage is cheapest to defend?

The control-change stage, because it is low volume, high signal, and mandatory for the attacker.

Logins are enormous in volume and mostly legitimate, so controls there impose friction on everyone. Contact-detail changes are rare by comparison and almost always precede a completed takeover, which makes them the highest-yield intervention point in the journey. A bank that hardens control changes and monitors reconnaissance patterns will stop more takeovers, with less customer friction, than one that adds another challenge at login.

### Why do most controls sit at the wrong stage?

Because authentication is a well-defined engineering problem and the rest of the chain is not.

There are standards, vendors, and clear success criteria for login. There is no product you can buy that tells you a session is browsing statements in an unusual order before changing an email address. So teams invest where the tooling is mature, and attackers move to where it is not. Correcting that imbalance is mostly about instrumenting the middle of the journey, which is where identity and access design meets fraud detection, and this guide to [identity and access management strategy](https://digiqt.com/blog/synthetic-identity-fraud-detection/) covers the platform side of that boundary.

> **Do you monitor what a session reads, or only what it changes?**
>
> [Talk to Digiqt about an account takeover chain assessment](https://digiqt.com/contact-us/)

## Which controls fit each stage of the chain?

Different controls for entry, for reconnaissance, for control change, and for extraction.

| Stage | Effective controls |
|---|---|
| Credential sourcing | Breach credential monitoring, forced reset on exposure, password reuse detection at set time |
| Access | Phishing-resistant authentication, device recognition, impossible-travel and velocity checks, credential stuffing rate limits |
| Reconnaissance | Session behaviour scoring, unusual navigation detection, alerting on access from new device without step-up |
| Control change | Step-up authentication, cooling-off delay, notification to previous contact details, blocking simultaneous changes |
| Extraction | Payee verification, new-payee limits, holds on high-risk payments, cross-channel correlation |

The stack works because the stages are sequential. An attacker who cannot change contact details cannot intercept verification, and one who cannot add a payee quietly cannot extract at scale, so even a successful login stops short of loss.

## Why is the contact-detail change the critical event?

Because it redirects every future verification message to the attacker.

Almost every completed takeover includes a change of phone number, email address, or trusted device, since without it the attacker keeps triggering messages to the genuine customer. That single fact should reshape your control design. Treat contact-detail changes, device registration, alert suppression, password changes, and limit increases as a distinct class of sensitive action with their own authentication requirement, their own monitoring, and their own audit trail.

### How should a cooling-off period work?

Change accepted, notification sent to the old details, and elevated-risk actions restricted for a defined window.

Do not block the change outright, because genuine customers change numbers constantly. Instead accept it, notify the previous contact details immediately with a clear route to dispute, and restrict high-risk actions such as new payees and high-value payments for a short window afterwards. Tune the window with data: measure how many disputes arrive within it and how many takeovers were stopped by it. Customers who genuinely changed numbers experience a brief restriction, and attackers lose the interception they depend on.

### Which changes must never be self-service alone?

Simultaneous changes to multiple contact channels, and any change immediately following a new-device login.

The combinations matter more than the individual events. A new device logging in and then changing both the phone number and the email address within minutes is a near-certain takeover, and no legitimate journey looks like that. Build detection on those combinations rather than on the events singly, and require a stronger check when they co-occur.

## How should authentication be strengthened without adding friction?

Phishing-resistant credentials at the front, and risk-based step-up reserved for sensitive actions.

NIST's guidelines are clear that biometrics are not secrets and should be used only as part of multi-factor authentication with a physical authenticator, which rules out treating a face or fingerprint check as sufficient on its own. The FIDO Alliance describes passkeys as phishing-resistant credentials based on public key cryptography, distinguishing synced passkeys backed up across a user's devices from device-bound ones offering the highest assurance. Adopting passkeys removes credential theft and reuse from your threat model, which is the largest single improvement available at the access stage. The migration path and fallback design are covered in [passkey authentication for financial applications](https://digiqt.com/blog/passkey-authentication-banking/).

### What should step-up actually look like?

A stronger check at the moment of a sensitive action, chosen by risk rather than applied uniformly.

Step up at control changes, new payees, unusual payments, and sessions with elevated behavioural risk. Do not step up on every login, since that trains customers to approve prompts reflexively, which is precisely the habit attackers exploit with fatigue attacks. Make prompts specific about what is being approved, including the action and the amount, so approval is an informed decision rather than a dismissal.

> **Are your customers trained to approve prompts without reading them?**
>
> [Talk to Digiqt about risk-based step-up design](https://digiqt.com/contact-us/)

## How do you detect a takeover while it is happening?

By scoring session behaviour and device signals continuously, not by checking at the door.

Reconnaissance has a shape: statements accessed in an unusual order, payee lists reviewed without action, limits inspected, settings pages visited in sequences no ordinary customer follows. Combined with device integrity signals and remote access indicators, that pattern is detectable in session, which is the argument for the instrumentation described in [behavioural biometrics and device intelligence](https://digiqt.com/blog/behavioral-biometrics-banking/). Then connect it to action: a high in-session score should raise the requirement for the next sensitive action rather than simply logging a number. Feed confirmed cases back into features and thresholds quickly, which is the loop set out in this guide to [real-time fraud detection](https://digiqt.com/blog/ai-in-fraud-detection-and-prevention-in-the-banking-industry/).

## How should the call centre be defended?

By replacing knowledge-based verification with something an attacker cannot obtain, and by monitoring agent-assisted changes.

The call centre is where strong digital controls get bypassed, because agents are trained and incentivised to help and because knowledge-based questions are answerable from breached data. Move to app-based approval where the customer confirms the interaction in an authenticated session, use call-side signals such as caller line integrity and voice channel anomalies where available, and cap what an agent can change without a second control. Then monitor agent-assisted changes with the same scoring you apply to digital ones, since a takeover routed through a human is still a takeover and it will not appear in your digital channel dashboards at all.

## How do you secure recovery flows without locking out real customers?

By treating recovery as re-proofing to the same standard as onboarding, with delay and notification.

Recovery is the deliberate bypass every authentication system contains, and attackers know it. Hold recovery to the same evidence standard as original onboarding rather than to a lower convenience standard, add a delay before newly recovered access can perform sensitive actions, notify all previously known contact channels, and log the full evidence chain. Where possible, offer a supported in-branch or video-verified route for genuine customers who cannot complete remote recovery, so the strict remote path does not become a customer service failure. Identity lifecycle design across these paths is exactly what this guide to [modernising identity and access management](https://digiqt.com/blog/synthetic-identity-fraud-detection/) addresses.

## What does response look like for a confirmed takeover?

Contain, preserve, notify, and reverse in that order, with a rehearsed runbook.

Containment first: suspend sessions, freeze outbound payments, revoke device trust, and block further control changes. Preserve evidence, including session logs, device data, and the full change history, before anything is reset. Notify the customer through a verified channel and explain what happens next. Then attempt recall of payments, recognising that on instant rails settlement is final and success depends on the receiving institution, which is the shared-liability dynamic covered in [authorised push payment fraud prevention](https://digiqt.com/blog/authorized-push-payment-fraud-prevention/). Rehearse this runbook, because the first genuine case always exposes a missing permission or an unreachable team.

## Which metrics prove the programme is working?

Containment time, takeover rate per channel, control-change interception, step-up outcomes, and false lockout cost.

| Metric | What it shows |
|---|---|
| Time from first suspicious access to containment | The single best summary of detection and response together |
| Confirmed takeovers per million sessions, by channel | Where attackers are actually succeeding, including the call centre |
| Control changes challenged and disputed within the cooling window | Whether your highest-value control is working |
| Step-up approval and abandonment rates | Whether prompts are informative or reflexive |
| Recovery flow abuse attempts and outcomes | Exposure on the deliberate bypass |
| Genuine customer lockouts and their resolution time | The cost side of every control above |

Report takeover rate by channel rather than in aggregate, because the aggregate hides the channel you have not hardened, and it is usually the one with a human in it.

## How should delivery be phased?

Harden control changes first, then instrument sessions, then adopt phishing-resistant credentials, then fix recovery and the call centre.

Start with sensitive-action hardening, including cooling-off windows and notifications, because it is inexpensive and stops the majority of completed takeovers. Instrument sessions next so reconnaissance becomes visible and step-up can be risk-driven. Roll out phishing-resistant authentication after that, as a migration rather than a switch, with fallback paths designed deliberately. Then address recovery and the call centre, which take longest because they involve process and people as much as software, and which is where attackers will concentrate once the digital path is closed.

Account takeover prevention is a chain problem, and chains fail at their weakest link rather than their strongest. The institutions that reduce losses are the ones that stopped adding controls to the login page and started defending the boring middle of the journey, where a phone number changes and nobody notices.

## Frequently Asked Questions

### Where does account takeover actually begin?

Outside your systems, with credentials sourced from breaches, phishing, or malware. By the time the attacker reaches your login page they already hold something that works.

### Which stage of the attack chain is cheapest to defend?

The control-change stage. Blocking or delaying contact-detail and device changes stops extraction even when the attacker already has valid access.

### Why is a contact-detail change the critical event?

Because it redirects every subsequent verification message to the attacker. Almost every completed takeover includes one, which makes it the highest-value control point in the whole journey.

### Do passkeys prevent account takeover?

They remove phishing and credential reuse, which is most of the entry problem. They do not protect recovery flows, call centre channels, or a customer coached into acting themselves.

### How should step-up authentication be triggered?

On risk and on sensitive actions rather than on every login. Step up at control changes, new payees, and unusual session behaviour, not at the front door for everyone.

### Why is the call centre often the weakest channel?

Because agents are trained to help and knowledge-based questions are answerable from breached data. Attackers route around strong digital controls by phoning instead.

### How do you secure recovery without locking out genuine customers?

Treat recovery as re-proofing rather than as a convenience path, with the same evidence standard as onboarding, plus a delay and a notification to the previous contact details.

### What is the most useful metric?

Time from first suspicious access to containment. It captures detection, alerting, and response together, and reducing it reduces loss more reliably than any single control.

## Sources

- [NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html)
- [FIDO Alliance, Passkeys](https://fidoalliance.org/passkeys/)
- [PSR, Authorised push payment scams](https://www.psr.org.uk/our-work/app-scams/)

Account Takeover Prevention Banking: Securing Digital Channels

Let Digiqt design authorized push payment fraud prevention that reads intent on both sides of the payment.

Stop Scam Payments Before They Settle

# Stopping Scam Payments the Customer Genuinely Authorised

Authorised push payment fraud is the fraud problem that defeats every control a bank spent the last decade building. Authentication succeeds because it is the real customer. Device checks pass because it is their device. The payment is within limits, to a valid account, with correct details, and the customer confirms it deliberately, sometimes twice.

The Payment Systems Regulator describes these as cases where someone is tricked into sending money to a fraudster posing as a genuine payee, and puts UK losses at £459.7 million in 2023. Prevention therefore cannot be about verifying identity, because identity is not in question. It has to be about reading intent and circumstance, on both sides of the payment, inside the seconds available before an irrevocable transfer settles.

## Why is APP fraud different from every other fraud problem?

Because the customer authorised it, so every identity-based control passes and there is nothing to reverse afterwards.

On instant rails settlement is final, which removes the recovery mechanism traditional fraud economics assume. Recovery depends on asking the receiving institution to return funds that have often already moved on. That changes where controls must sit and what they must detect: not whether this is the right person, but whether this person is being deceived right now.

### What does authorised actually mean for your controls?

That your only remaining levers are intent detection, intervention design, and receiving-side interception.

Intent cannot be observed directly, so it is inferred from circumstance and behaviour. Intervention is what you do with that inference, and its design determines whether the inference matters at all. Receiving-side interception is the underused third lever, because a fraudster's account behaves very differently from a genuine one even when the payer looks entirely normal. Any prevention programme that only works on the payer's side has given up two thirds of the available surface.

### Why does the receiving side matter as much as the sending side?

Because mule account behaviour is often a clearer signal than anything visible on the payer's side, and because the cost is now shared.

Under UK rules, reimbursement costs are split equally between the sending and receiving firms, with most victims reimbursed within five business days and additional protections for vulnerable customers. That turns receiving-side detection from goodwill into direct financial self-interest. An account receiving unusual inbound value from unrelated parties, moving it onward within minutes, and showing onboarding characteristics typical of a recently opened mule is detectable, and detecting it protects both your own losses and your share of someone else's.

> **Is your APP programme entirely focused on the paying customer?**
>
> [Talk to Digiqt about a two-sided APP fraud assessment](https://digiqt.com/contact-us/)

## Which signals actually indicate a scam in progress?

Behavioural signals from the session, payee novelty, contextual anomalies, and receiving-side account patterns.

| Signal group | Examples | Strength |
|---|---|---|
| Session behaviour | Long hesitation on the amount field, repeated correction of payee details, unusually slow or unusually rushed entry, evidence of reading from another source | High when combined |
| Device and channel | New device, remote access tooling present, concurrent call activity where observable | High |
| Payee novelty | First payment to this payee, payee recently added, payee associated with prior reports | High |
| Payment context | Amount atypical for the customer, near a balance or limit, unusual time, sequence of escalating payments | Medium to high |
| Customer context | Age or vulnerability indicators, recent change of contact details, recent unusual login patterns | Medium, use carefully |
| Receiving side | Inbound from unrelated parties, rapid onward movement, account recently opened, mismatch with stated purpose | Very high |

### What does behavioural intelligence add over rules?

It detects the pattern of a coached customer, which no static rule expresses.

Rules catch what you have already seen: a threshold, a new payee, a country. Behavioural intelligence catches how the payment is being made, which is where deception shows up. A customer being talked through a transfer by a stranger types differently, pauses differently, and navigates differently from one paying a builder they know. None of those signals is conclusive alone, which is exactly why they need a model rather than a rule, and why the model must combine them with payee and context features. The detection architecture is the same as any real-time scoring problem, and the precomputation constraints in this guide to [real-time fraud detection](https://digiqt.com/blog/ai-in-fraud-detection-and-prevention-in-the-banking-industry/) apply without modification.

### How is the threat itself changing?

Scams are becoming more convincing and more scalable, which raises the value of behavioural signals rather than lowering it.

Synthetic voice and generated text have made impersonation cheaper and more plausible, so controls that depend on a customer recognising a fake are weakening, as set out in this look at AI-enabled phishing and synthetic social engineering. What does not change is that a deceived customer behaves differently from an undeceived one, and that a mule account cannot hide its cash flow pattern. Both are structural signals rather than content signals, which is why they hold up as the deception gets better.

## How should interventions be designed?

As a tiered ladder from targeted warning to hold and contact, with hard blocks reserved for the highest confidence.

| Risk level | Intervention | Cost to genuine customers |
|---|---|---|
| Low | Proceed, log for feedback loop | None |
| Medium | Specific named-scam warning matched to the pattern | Small |
| Medium to high | Dynamic questions about the payment's purpose and how it was arranged | Moderate |
| High | Short hold plus outbound contact attempt | Moderate to high |
| Very high | Block, with a clear route to review | High |

### Why do generic warnings fail?

Because customers see them on every payment and learn to dismiss them.

A warning that says payments can be scams teaches nothing and gets clicked through. A warning that says this payment resembles an impersonation scam, that a genuine organisation will not ask you to move money to a safe account, and that asks whether someone contacted you first, engages the specific deception. Matching warning content to the detected pattern is one of the highest-return changes available, and it is a content and product decision more than an engineering one. Measure dismissal rates per warning type and rewrite the ones that are always dismissed.

### When is delaying a payment the right control?

When the score is high and urgency is part of the scam, which it almost always is.

Scams depend on time pressure, so a short hold with an outbound contact attempt removes the mechanism rather than the payment. Design it explicitly: how long, who attempts contact, what happens if the customer cannot be reached, and how the customer overrides. Then measure outcomes, because holds that never change a customer's mind are pure friction while holds that stop a meaningful share are cheap insurance against an irrecoverable loss. Note that this control only exists if your platform can hold a payment without failing it, which is a design decision in the payment path rather than in the fraud engine, as covered in [instant payment participation architecture](https://digiqt.com/blog/fednow-rtp-integration/).

### What role does payee verification play?

It removes the misdirection cases and gives the scam detection model a strong feature.

Name checking catches wrong-account payments outright and provides a signal for everything else, since a scam payment frequently goes to an account whose name does not match what the victim believes. In the euro area, verification of payee has been required since October 2025 under the Instant Payments Regulation, and the PSR has overseen the continued rollout of confirmation of payee in the UK. Feed the verification outcome into the risk score rather than treating it as a separate gate, and design the close-match experience carefully, as discussed in [confirmation of payee architecture](https://digiqt.com/blog/confirmation-of-payee-architecture/).

> **Are your scam warnings generic enough that customers ignore them?**
>
> [Talk to Digiqt about intervention design and warning effectiveness](https://digiqt.com/contact-us/)

## How should receiving-side detection be built?

As continuous account behaviour monitoring, with onboarding signals retained and inbound patterns scored.

Mule accounts are identifiable from the pattern of use rather than from the identity behind them. Score inbound receipts from unrelated parties, rapid onward dispersal, mismatch between actual activity and stated account purpose at onboarding, clusters of accounts sharing devices or contact details, and dormancy followed by sudden throughput. Retaining onboarding data in a form the monitoring model can use is what makes this possible, which is why identity and onboarding architecture matters here, as described in this guide to [digital onboarding and KYC automation](https://digiqt.com/blog/digital-account-opening-platform/). Then act: hold suspicious inbound credits before they can be dispersed, because a hold on the receiving side is the only intervention that still works after the payer has authorised.

## What does shared liability change architecturally?

It makes receiving-side controls a funded priority and makes case data a shared asset.

When the receiving firm bears half the reimbursement cost, the business case for mule detection stops depending on reputational argument. Practically, that means building three things: receiving-side scoring with the ability to hold, a case management process that can respond to another institution's recall request within hours rather than days, and reporting that attributes losses to sending-side and receiving-side causes separately so investment goes where the losses are. Institutions that cannot split their APP losses that way are usually over-investing on the payer side and under-investing on the account they opened for the fraudster.

## How should institutions share intelligence?

Through structured, timely exchange of account and pattern signals rather than case-by-case emails.

The signals with the shortest useful life are the ones about accounts currently receiving scam proceeds, and they are worthless a week later. Where industry mechanisms exist, integrate them as data feeds into scoring rather than as a reference someone checks manually. Where they do not, the internal equivalent still matters: a confirmed case in your own institution should tighten limits, update payee reputation, and adjust model features within minutes, not at the next model release. The PSR has also committed to promoting improved fraud intelligence sharing between firms, so expect this surface to grow and build the ingestion path now.

## How do you measure prevention without gaming it?

By pairing value prevented with customer friction, and by attributing losses to a specific control failure.

| Metric | What it shows | Why it needs a pair |
|---|---|---|
| Value prevented | Payments stopped that were confirmed scams | Meaningless without the false positive cost |
| False intervention rate | Genuine payments delayed or blocked | Meaningless without prevention value |
| Warning dismissal rate by type | Whether warnings are read | Identifies content that needs rewriting |
| Hold conversion | Share of held payments the customer abandons | Distinguishes useful holds from friction |
| Receiving-side interception | Value held before dispersal | The lever most banks underuse |
| Loss attribution split | Sending-side versus receiving-side cause | Directs investment honestly |
| Reimbursement outcomes | Cost borne and cases upheld | Connects prevention to financial result |

Report fraud loss and false intervention together, always. Loss alone rewards blocking everything, conversion alone rewards passivity, and only the pair produces a design anyone can defend to both the risk committee and the commercial teams.

## How should delivery be phased?

Payee verification and targeted warnings first, then behavioural scoring, then receiving-side detection, then intelligence sharing.

Start with payee verification and pattern-specific warnings, which are inexpensive and reduce losses immediately. Add behavioural scoring next, with the intervention ladder configured as policy rather than code so risk teams can tune it without a release. Build receiving-side detection third, because it takes longer and needs onboarding data, and it is the phase that changes your loss profile most once shared liability applies. Then integrate intelligence sharing and close the feedback loop so confirmed cases tighten controls within minutes. Behavioural signal collection sits underneath all of it, which is why the instrumentation described in [behavioural biometrics and device intelligence](https://digiqt.com/blog/behavioral-biometrics-banking/) should be sequenced alongside rather than after.

APP fraud is the one payment risk where the technology cannot carry the whole answer, because the deceived customer is the one pressing the button. What technology can do is notice that the button is being pressed under duress, make the warning specific enough to land, buy a few minutes of delay, and stop the money moving on once it arrives in an account that should never have received it.

## Frequently Asked Questions

### Why is APP fraud different from other payment fraud?

Because the customer genuinely authorises the payment. Authentication succeeds, the credentials are real, and the systems work correctly, so detection has to read intent rather than identity.

### Where is APP fraud easiest to detect?

On the receiving side. A mule account shows unusual inbound patterns and rapid onward movement, which are often clearer signals than anything visible on the payer's side.

### What behavioural signals indicate a scam in progress?

Hesitation and correction patterns during entry, an unusually long session, evidence of being coached, a first-time payee, an atypical amount, and rushed navigation to the payment screen.

### Why do generic scam warnings fail?

Because customers see them on every payment and stop reading. Warnings only change behaviour when they name the specific scam pattern the payment resembles.

### Is delaying a payment an acceptable control?

For high-risk cases, yes. A short hold with a contact attempt breaks the urgency scammers rely on, and it is far cheaper than reimbursing an irrecoverable payment.

### How does shared reimbursement change the architecture?

It makes receiving-side detection a direct financial concern rather than a courtesy, since the receiving firm bears half the cost of a reimbursed scam under UK rules.

### Can behavioural models be deployed without hurting genuine customers?

Yes, if intervention is tiered. Most risk should be handled by better warnings and questions rather than blocks, with hard stops reserved for the highest scores.

### What single metric matters most?

Value prevented per unit of customer friction. Fraud loss alone rewards blocking, and conversion alone rewards passivity, so only the pair drives the right design.

## Sources

- [PSR, Authorised push payment scams](https://www.psr.org.uk/our-work/app-scams/)
- [ECB, Instant Payments Regulation](https://www.ecb.europa.eu/paym/integration/retail/instant_payments/html/instant_payments_regulation.en.html)
- [RTP Network, The Clearing House](https://www.theclearinghouse.org/payment-systems/rtp)

Authorized Push Payment Fraud Prevention With Behavioral Signals

Let Digiqt design behavioral biometrics and device intelligence that improves fraud detection without slowing your app.

See Risk In The Session, Not Just At Login

# Reading How Someone Uses Your App, Not Just Who They Claim to Be

Authentication answers a question banks have largely solved: is this the right credential on a known device. The problems that now cost the most money sit outside that question entirely. A genuine customer, on their own phone, correctly authenticated, being talked through a transfer by someone impersonating their bank. Or an account taken over mid-session after every credential check passed.

Behavioural biometrics and device intelligence exist to fill that gap. They do not verify identity better, they describe how a session is being used, which is the only remaining place to look when the credentials are real and the device is genuine. Getting behavioral biometrics banking capability right is largely about honest scope, low overhead, and privacy decisions made before collection starts.

## What do behavioural biometrics and device intelligence measure?

Behaviour describes how the human interacts with the app, and device intelligence describes the environment they are doing it in.

Keeping the two separate matters, because they have different reliability, different privacy implications, and different failure modes. Most vendors bundle them, and most banks benefit more from the device side in the first year while the behavioural models mature on their own traffic.

| Signal family | Examples | Best used for |
|---|---|---|
| Typing dynamics | Keystroke timing, correction frequency, hold durations | Account takeover, coached-session detection |
| Touch and gesture | Pressure, contact area, swipe velocity, scroll rhythm | Continuous session consistency |
| Motion and orientation | How the device is held and moved during use | Distinguishing genuine handling from automation |
| Navigation patterns | Route through the app, dwell times, hesitation on fields | Scam and duress indicators |
| Device identity and integrity | Device fingerprint, rooting or jailbreak state, emulator detection, app tampering | Blocking automation and cloned environments |
| Remote access indicators | Screen sharing or remote control tooling present | Very strong scam signal |
| Network characteristics | Connection type, proxy and VPN indicators, impossible travel | Contextual risk |

### Why is continuous scoring more valuable than a login check?

Because the money leaves at the payment, and the session's risk can change entirely between login and that moment.

A login-time decision is a single observation with no view of what happens next. Continuous scoring lets you evaluate risk at the moment that matters, using everything the session has revealed since it began, including hesitation patterns during payee entry and the presence of remote access tooling that appeared after login. That is exactly the profile of an authorised push payment scam or a mid-session takeover, and it is invisible to any control that fires once at the door. The relationship to intent-based scam detection is direct, and the intervention design for it is covered in [authorised push payment fraud prevention](https://digiqt.com/blog/authorized-push-payment-fraud-prevention/).

### Which signals give the best return first?

Device integrity and remote access detection, before any behavioural model.

Device-side signals are deterministic, easy to explain, and immediately actionable: an emulator, a tampered app, or an active remote control session is a strong reason to intervene regardless of behaviour. Behavioural models need volume, tuning, and per-population calibration before they earn trust. Sequencing device intelligence first also builds the collection pipeline the behavioural work will need, which makes it the cheaper starting point in both effort and risk.

> **Is your only risk decision made at login?**
>
> [Talk to Digiqt about session risk and device intelligence design](https://digiqt.com/contact-us/)

## Where does this sit in the authentication model?

As a risk input feeding decisions, never as a credential in its own right.

The distinction is not academic. NIST's digital identity guidelines state that biometrics should be used only as part of multi-factor authentication with a physical authenticator, note that biometric characteristics are not secrets and can be captured without the subject's knowledge, and set requirements including a false match rate of one in a thousand or better, presentation attack detection demonstrating at least ninety percent resistance per attack type under ISO/IEC 30107-3, limits of five or ten consecutive failed attempts depending on that detection, and an authenticated protected channel before sample capture. Behavioural signals are weaker than the physiological biometrics those requirements govern, which reinforces the point: treat them as evidence about a session, not as proof of a person.

### How do passkeys change the picture?

They remove phishing and credential theft, which makes behavioural signals more important rather than less.

The FIDO Alliance describes passkeys as phishing-resistant credentials based on public key cryptography that replace passwords, distinguishing synced passkeys backed up across a user's devices from device-bound passkeys that never leave one device and offer the highest assurance. Adopting them eliminates a large category of attack. What remains is precisely the category behavioural signals address: the genuine customer, with their genuine passkey, on their genuine device, being deceived. Deploy passkeys for the credential problem and behavioural intelligence for the intent problem, and stop expecting either to solve the other.

### What should behavioural signals never be used for?

Sole authorisation, silent denial of service, or inferences about the person rather than the session.

Do not let a behavioural score alone approve a high-value action, because a false negative has no second line of defence. Do not use it to block silently without a route to resolution, because a customer with a new injury, a new phone, or a different posture will fail your model through no fault of theirs. And keep inferences scoped to session risk rather than to characteristics of the individual, which is both an ethical line and, in several jurisdictions, a legal one.

## How should the collection layer be built?

As a minimal SDK that computes features on the device and transmits derived signals rather than raw streams.

Send derived features, not raw telemetry. Raw keystroke and touch streams are large, sensitive, and rarely necessary once features are defined, so computing on device reduces both privacy exposure and bandwidth. Set an explicit performance budget for the SDK covering CPU, memory, battery, app size, and startup time, and test it on low-end devices representative of your actual customer base rather than on the newest handset in the office. Then monitor it in production, because an SDK that degrades app responsiveness will cost you more in abandoned sessions than it saves in fraud, and that trade will be invisible unless you measure it.

### What must be minimised or kept off the wire?

Anything resembling content, plus any identifier you do not need.

Never collect what is typed, only how it is typed. Keep field-level content out of the pipeline entirely, exclude credential entry from raw capture, and avoid collecting persistent identifiers beyond what your device identity requires. Document what each signal is for, and drop signals nobody uses, because unused sensitive data is pure liability. The segmentation and least-privilege reasoning here follows the same model as this guide to zero-trust security architecture.

## How should the scoring service be architected?

As a continuously updated session profile scored in memory, with decisions taken in tens of milliseconds.

Features must be maintained during the session rather than assembled at the decision point, because a payment screen cannot wait for a batch of lookups. Keep the scoring service co-located with the decision path, hold the session profile in memory, and define behaviour for a missing or stale profile so the decision degrades gracefully instead of hanging. The failure modes are identical to any inline scoring path and are set out in this analysis of [latency in real-time risk scoring APIs](https://digiqt.com/blog/real-time-risk-engine/). Feed confirmed fraud outcomes back into features and thresholds quickly, which is the loop described in [real-time fraud detection](https://digiqt.com/blog/ai-in-fraud-detection-and-prevention-in-the-banking-industry/), and use the same score in card-not-present authentication decisions rather than maintaining a second signal set, as covered in [3-D Secure and tokenisation infrastructure](https://digiqt.com/blog/3d-secure-tokenization-infrastructure/).

> **Assembling session features at the moment a payment is submitted?**
>
> [Talk to Digiqt about session scoring latency and feature design](https://digiqt.com/contact-us/)

## What privacy and consent obligations shape the design?

Disclosure, lawful basis, minimisation, and retention, all settled with counsel before collection begins.

Behavioural interaction data may be treated as biometric or otherwise sensitive personal data depending on jurisdiction, and some regimes impose specific consent, notice, and retention requirements on biometric identifiers. Decide the lawful basis per market before you write the SDK, because retrofitting consent to a live collection pipeline is far harder than designing for it. Then be explicit in your privacy notice about what is collected and why, keep retention short and defined per signal, minimise identifiers, and support deletion. Where onboarding already captures identity data, keep the two pipelines separate with a clear boundary, since combining behavioural session data with identity verification records raises questions neither system was designed to answer. The identity side of that boundary is covered in this guide to [digital onboarding and KYC automation](https://digiqt.com/blog/digital-account-opening-platform/).

## How should vendors be evaluated?

On transparency, footprint, data handling, and measured performance against your own traffic.

| Criterion | What to require | Why it matters |
|---|---|---|
| Signal transparency | A documented list of every signal collected | You cannot write a privacy notice for a black box |
| Score explainability | Reason codes behind each score | Needed for customer complaints and audit |
| SDK footprint | Measured CPU, battery, size, startup impact | Protects conversion on low-end devices |
| Data residency and retention | Where data is processed and for how long | Determines regulatory viability per market |
| Feature and score ownership | Your access to your own features and scores | Prevents lock-in and preserves your history |
| Proof on your traffic | A paid pilot measured against your fraud cases | Vendor benchmarks reflect someone else's customers |
| Model update process | How and when models change, and your control over it | A silent model change can move your false positive rate overnight |

Insist on a pilot measured against your own labelled fraud outcomes. Every vendor's published lift figures come from a different population, and the honest ones will expect the request.

## How do you measure whether it works?

By lift over existing controls, false intervention cost, coverage, and app performance impact.

Measure detection lift as additional confirmed fraud caught relative to your existing controls, not as absolute detection, because most of what a new model catches was already being caught. Track false intervention rate and its cost, since behavioural models generate friction for legitimate customers who changed device or circumstance. Report coverage, meaning the share of sessions with a usable profile at the decision point, because low coverage silently limits the value. Watch app performance and abandonment as a control metric rather than an engineering curiosity. And review score stability for individual customers over time, because a model that reclassifies the same person repeatedly will erode trust in every downstream decision.

## How should delivery be phased?

Device intelligence first, then collection and shadow scoring, then intervention, then behavioural models.

Deploy device integrity and remote access detection first, since the signals are explainable and immediately useful. Build the collection pipeline and run scoring in shadow mode next, logging decisions without acting on them, which gives you a labelled baseline and a realistic false positive estimate before any customer is affected. Then connect the score to the intervention ladder, starting with warnings and step-up rather than blocks. Then invest in behavioural models tuned on your own population, and only after coverage and stability are proven. Settle the privacy work before phase one rather than in parallel, because it constrains the SDK design and cannot be retrofitted cheaply.

Behavioural biometrics is one of the few fraud technologies that is genuinely invisible to almost every customer and decisive for a small number of sessions. That is the right ambition for it. Treat it as a strong risk signal that improves decisions you already make, keep its privacy footprint small and documented, and stop short of asking it to be an identity control it was never capable of being.

## Frequently Asked Questions

### What do behavioural biometrics actually measure?

How a person interacts with a device: typing rhythm, touch pressure and size, scroll and swipe dynamics, device orientation habits, and navigation patterns across a session.

### Can behavioural biometrics replace authentication?

No. NIST is explicit that biometrics are not secrets and should be used only as part of multi-factor authentication with a physical authenticator. Behavioural signals are risk inputs, not credentials.

### What is the difference between behavioural biometrics and device intelligence?

Behaviour describes how the human interacts. Device intelligence describes the environment: device identity, integrity, emulation, remote access tooling, and network characteristics.

### Why is continuous scoring more valuable than a login check?

Because the risk in banking apps sits at the payment, not the login. A session can start legitimately and be taken over or coached by a scammer minutes later.

### Do passkeys make this unnecessary?

No. Passkeys remove phishing and credential theft, which is a large win, but they cannot tell you the genuine customer is being socially engineered while using their own device.

### What latency budget applies to session scoring?

Tens of milliseconds at the decision point, which means features are computed continuously during the session rather than assembled when a payment is submitted.

### What are the main privacy obligations?

Behavioural data may be treated as biometric or sensitive personal data in some jurisdictions, so disclosure, lawful basis, minimisation, and retention limits must be settled with counsel before collection starts.

### How should vendors be evaluated?

On signal transparency, model explainability, SDK footprint, data residency, false positive behaviour on your own traffic, and whether you retain your own scores and features.

## Sources

- [NIST SP 800-63B, Digital Identity Guidelines: Authentication and Lifecycle Management](https://pages.nist.gov/800-63-3/sp800-63b.html)
- [FIDO Alliance, Passkeys](https://fidoalliance.org/passkeys/)
- [PSR, Authorised push payment scams](https://www.psr.org.uk/our-work/app-scams/)

Behavioral Biometrics Banking: Device Intelligence in Mobile Apps

Let Digiqt design federated fraud intelligence sharing that improves detection while keeping raw data in house.

Share Fraud Signals, Not Customer Data

# Sharing Fraud Signals Between Banks While Keeping Customer Data In House

Every fraud team knows the shape of the problem. A mule account receives funds from four institutions in one morning, and each of those institutions sees a single unremarkable payment. The pattern is obvious from above and invisible from inside any one bank, which is why detection built purely on internal data has a ceiling that no additional modelling will lift.

The obstacle to crossing that boundary has never really been technical. It is that sharing customer data between competing institutions raises privacy, liability, and competition questions that are slower to resolve than any engineering task. What has changed is that the technology now allows useful signals to move without the underlying customer data moving with them, which reframes the conversation from whether to share data to what exactly needs to cross the boundary.

## Why does fraud intelligence need to cross institutional boundaries?

Because fraud networks operate across institutions while detection operates inside them.

The asymmetry is structural. A fraudster deliberately distributes activity across banks to stay below every individual threshold, and each institution's view is a fragment. The BIS Innovation Hub's Project Aurora, reported in May 2023, tested exactly this proposition and found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes, such as mule and layering activity, while reducing false positives by up to eighty percent compared with the current siloed and rules-based approach. That last figure matters as much as the first: collaboration improves precision, not just recall, because context resolves ambiguity.

### What can a single institution never see on its own?

Onward movement, cross-institution clustering, and whether a counterparty is already known elsewhere.

You cannot see where funds went after leaving your customer's account, how many other banks sent value to the same beneficiary this morning, whether the device behind an application has appeared at three other institutions this week, or whether an account you are about to open belongs to a network already confirmed as fraudulent. Each of those is decisive information available somewhere in the system and nowhere in your data warehouse.

### Why does precision improve rather than degrade?

Because most false positives come from missing context, and context is exactly what the other institution holds.

An unusual payment to a new payee looks risky in isolation. If the receiving account has a long, ordinary history at another bank, the risk falls sharply. Sharing therefore lets you release genuine payments with more confidence as well as stop fraudulent ones, which is the argument that wins over commercial stakeholders who otherwise see fraud investment as pure friction.

> **Is your detection ceiling set by the data you do not have rather than the models you run?**
>
> [Talk to Digiqt about a fraud data sharing feasibility review](https://digiqt.com/contact-us/)

## What are you actually trying to share?

Markers, patterns, relationship signals, and model improvements, almost never raw customer records.

| What is shared | Example | Privacy sensitivity | Usual mechanism |
|---|---|---|---|
| Confirmed bad markers | Account or instrument confirmed as receiving fraud proceeds | Medium, refers to identifiable accounts | Hashed identifier exchange |
| Typology patterns | A described scam pattern with indicative features | Low | Structured bulletins or feeds |
| Graph relationship signals | Device or contact attribute seen across institutions | High | Privacy-preserving set intersection |
| Aggregate risk scores | A score or band for a counterparty on request | Medium | Query API with strict controls |
| Model improvements | Updated parameters learned from local data | Low if properly constructed | Federated learning |
| Raw customer records | Full transaction and identity data | Very high | Rarely justified, usually avoidable |

Working through that table is the first design task, because most institutions discover that eighty percent of the value they want comes from the first two rows, which are also the easiest to justify legally.

## Which architectures are available?

Five practical patterns, from simple hashed exchange to federated learning, with increasing capability and complexity.

| Pattern | What crosses the boundary | Strength | Cost and complexity |
|---|---|---|---|
| Central utility | Data submitted to a shared operator | Rich analysis, single view | High legal and governance load |
| Hashed identifier exchange | Salted hashes of account or contact identifiers | Simple, fast, well understood | Low |
| Private set intersection | Cryptographically protected overlap only | Reveals only shared elements | Medium |
| Secure multiparty computation | Computation results, never inputs | Strong guarantees, flexible queries | High, and performance limited |
| Federated learning | Model updates, never records | Learns patterns across institutions | Medium to high, needs coordination |
| Trusted execution environments | Data processed in an attested enclave | Practical for richer joint analysis | Medium, depends on hardware trust |

### When is hashed identifier exchange sufficient?

Whenever the question is simply whether a counterparty is already known to be bad.

That question carries a large share of the practical value and needs nothing exotic: a shared salting scheme, a query interface, rate limits, and audit. It resolves the mule account problem in the case that matters most, where another institution has already confirmed fraud on an account you are about to pay. Start here rather than with the most sophisticated option, because it can be live in months while a multiparty computation programme is still in legal review.

### When do you need federated learning?

When the value lies in patterns nobody has labelled yet rather than in confirmed lists.

Federated learning improves a shared model using each participant's local data without that data leaving its institution, which fits fraud well because the useful patterns are distributed and the labels are held privately. It requires coordination on features, model versioning, update validation, and defence against a participant contributing poisoned updates, so the operational overhead is real. Aurora's finding rests on this class of technique, and the practical lesson is that the privacy technology is no longer the hard part.

### Where do trusted execution environments fit?

Where you need richer joint analysis than set intersection allows but cannot justify a central data pool.

An attested enclave lets participants compute over combined data with technical guarantees about what the operator can see, which suits graph construction across institutions. The trade is that you are trusting hardware and attestation rather than a legal agreement alone, and your risk function will want to understand that shift. It is a reasonable middle path, and it should be evaluated against a central utility on governance grounds rather than purely on technical ones. The consortium design questions this raises are covered in this guide to multi-party data sharing and consortium models.

## What must be settled before any data moves?

Lawful basis, purpose limitation, liability, residency, retention, and correction rights.

This is the phase that determines whether the programme happens, and engineering cannot proceed past design without it. Establish the lawful basis for sharing in every jurisdiction involved, define purpose limitation narrowly enough to be defensible and broadly enough to be useful, agree liability where a shared marker turns out to be wrong, settle where data may be processed, set retention per signal type, and define how a customer wrongly marked gets corrected across every participant. Multi-jurisdiction operation multiplies each of these, as set out in this guide to [privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/), and consent and provenance need to be tracked at the record level for exactly the reasons described in consent, provenance and sensitive data.

### Who governs the consortium?

A defined body with membership criteria, contribution obligations, dispute resolution, and exit terms.

Governance failure kills more of these initiatives than technology does. Agree membership criteria and the standard each participant must meet, contribution obligations so the scheme does not become a few contributors subsidising many consumers, a process for challenging and removing incorrect markers with a service level attached, dispute resolution, and exit terms covering what happens to contributed signals when a member leaves. Write the exit terms early, because they are much harder to negotiate once the scheme is valuable.

> **Have you settled liability for a shared marker that turns out to be wrong?**
>
> [Talk to Digiqt about consortium governance design](https://digiqt.com/contact-us/)

## How do you prevent the system being abused?

Rate limits, purpose binding, reciprocity, per-participant audit, and monitoring of consumption patterns.

A fraud intelligence network is itself an information disclosure surface, and it must be designed defensively. Bind every query to a stated purpose and a real transaction or application, rate limit per participant and per subject, log every query with the requesting institution recorded, and monitor query-to-contribution ratios so a member consuming heavily without reporting anything becomes visible. Watch for enumeration patterns exactly as you would on any lookup service, and give the governance body the ability to throttle or suspend a participant. Treat abuse monitoring as a launch requirement rather than a later addition, because retrofitting it to a live scheme means explaining to members why you did not have it.

## How do you keep shared signals useful?

By decaying them, requiring confirmation to refresh, and measuring precision by signal age and type.

Fraud markers age badly. An account confirmed as a mule three weeks ago may have been closed, remediated, or returned to a genuine customer, and treating that marker as permanent generates false positives that erode trust in the whole scheme. Apply time-based decay, require re-confirmation to refresh a marker, and measure precision separately by signal age and signal type so participants can weight what they receive. Then close the loop: when a participant acts on a shared signal and finds it wrong, that outcome must flow back and adjust the marker, which is the discipline that separates a living network from a stale blocklist.

## What does a workable reference architecture look like?

Local detection, a contribution gateway, a shared exchange layer, and local consumption, with nothing raw leaving the institution.

Keep detection local and let each institution decide what qualifies as a confirmed signal. Put a contribution gateway between your systems and the exchange that enforces what may leave, applies hashing or protection, strips anything unnecessary, and logs every outbound item for audit. Run the exchange as the agreed mechanism, whether hashed lookup, set intersection, enclave, or federated learning coordinator. Then consume signals locally as features in your own models rather than as automatic decisions, so a shared marker informs your score instead of overriding your judgment. That last point matters for accountability: your decisions remain yours to explain, which connects directly to the graph-based internal detection described in [using graph databases to uncover fraud networks](https://digiqt.com/blog/graph-database-systemic-risk-analysis/) and to the linkage work in [synthetic identity fraud detection](https://digiqt.com/blog/synthetic-identity-fraud-detection/).

## How should delivery be phased?

Legal first, then hashed exchange, then relationship signals, then federated learning.

| Phase | Duration | Deliverable |
|---|---|---|
| Legal and governance foundation | 3 to 6 months | Lawful basis, purpose limitation, liability, correction process, member agreement |
| Contribution gateway | 2 to 3 months | Outbound control, protection, logging, audit |
| Hashed marker exchange | 2 to 3 months | Query and contribution APIs, rate limits, abuse monitoring, decay |
| Local consumption as features | 1 to 2 months | Shared signals feeding internal scores, not automatic decisions |
| Relationship signal sharing | 3 to 4 months | Private set intersection or enclave-based attribute overlap |
| Federated learning | 4 to 6 months | Shared model, update validation, poisoning defences, version governance |

The legal phase runs longest and cannot be parallelised away, so start it before the architecture is finalised and let its outcome shape the technical choice rather than the reverse. Institutions that build first and seek approval later usually discover the approval requires a different architecture.

## Which metrics prove the sharing is worth it?

Detection lift attributable to shared signals, precision by signal type, contribution balance, and query response time.

Measure lift specifically: cases detected or prevented that internal signals alone would have missed, which requires holding out shared features in evaluation. Report precision per signal type and age so members can calibrate trust. Track contribution balance across members, because a scheme where a few institutions contribute everything will collapse. Watch query response time, since a lookup too slow for a payment path will be bypassed. And record correction turnaround, meaning how long a wrong marker takes to be removed everywhere, as that number is what protects genuine customers and it is the one participants will be asked about publicly.

Fraud is one of the few areas in banking where competitors have entirely aligned interests, and the technology to act on that alignment is now well proven. What remains is unglamorous: agreeing what may cross the boundary, building a gateway that enforces it, and running the scheme so that signals stay fresh and members stay honest.

## Frequently Asked Questions

### Why does fraud intelligence have to cross institutional boundaries?

Because fraud networks do. Money moves between banks, so any single institution sees fragments of a pattern that is only coherent when the fragments are combined.

### Is there evidence that collaborative detection actually works better?

Yes. The BIS Innovation Hub's Project Aurora found privacy-enhancing technologies with network analysis detected potentially up to three times more complex schemes and cut false positives by up to eighty percent versus siloed rules.

### What should actually be shared between institutions?

Confirmed account and instrument markers, typology patterns, graph relationship signals, and model improvements. Raw customer records almost never need to move.

### When is hashed identifier exchange enough?

When you only need to ask whether a counterparty is already known as fraudulent. It is simple, fast, and adequate for a large share of practical value.

### When do you need federated learning instead?

When the value is in patterns rather than in known-bad lists, since federated learning improves a shared model from local data without that data leaving each institution.

### How do you stop a participant fishing for information?

Rate limits, query purpose binding, reciprocity requirements, per-participant audit, and monitoring of query-to-report ratios that reveal a member consuming without contributing.

### What must be settled before any data moves?

Lawful basis, purpose limitation, participant liability, data residency, retention, and the process for correcting a wrong marker. These are slower than the engineering and gate it.

### How do you keep shared signals useful over time?

Decay them. Fraud markers age quickly, so apply time-based weighting, require confirmation to refresh, and measure precision by signal age rather than treating all markers equally.

## Sources

- [BIS Innovation Hub, Project Aurora](https://www.bis.org/about/bisih/topics/fmis/aurora.htm)
- [PSR, Authorised push payment scams](https://www.psr.org.uk/our-work/app-scams/)

Federated Fraud Data Sharing Without Exposing Customer Data

Let Digiqt design synthetic identity detection built on entity resolution, graph features, and models you can explain.

Detect Identities That Were Never Real

# Finding Customers Who Were Never Real in the First Place

Most fraud detection assumes there is a victim whose identity was misused and a genuine person whose behaviour you can compare against. Synthetic identity fraud removes both assumptions. There is no victim to report the account, no legitimate behavioural history to deviate from, and frequently no real person at all, just a carefully cultivated file that has behaved impeccably for two years.

That is why the losses usually sit in credit rather than in fraud. The account pays on time, builds limits, then draws everything and disappears, and the case is written off as a charge-off with nobody to pursue. Synthetic identity fraud detection is therefore less about scoring an application and more about finding relationships between identities that should have none.

## What makes synthetic identity fraud different from impersonation?

There is no real victim, so nothing gets reported and the account looks like a good customer for a long time.

In impersonation, a real person eventually notices and disputes. In a synthetic case, the identity is fabricated from a mixture of real and invented attributes, often a genuine identifier paired with an invented name and date of birth, and then deliberately cultivated with small credit products and consistent repayment. Nobody complains, so the only detection opportunity is one your systems create for themselves.

### Why does it pass onboarding checks?

Because every attribute is individually valid, and attribute-level checks cannot see the combination.

Identity proofing is designed to resolve a claimed identity to a unique individual, validate the evidence, confirm that individual exists in the real world, and verify that the applicant is that individual. NIST's guidelines set out that structure along with identity assurance levels and a scale of evidence strength from unacceptable to superior. Synthetic identities are built specifically to satisfy those checks attribute by attribute: the identifier exists, the address is real, the documents may be genuine. What fails is the fourth outcome, verifying the association between the applicant and the identity, and that is exactly the part hardest to automate remotely. Raising evidence requirements helps at the margin, and it also raises friction for genuine customers, which is why detection cannot rest on proofing alone. The onboarding architecture that captures this evidence properly is covered in this guide to [digital onboarding and KYC automation](https://digiqt.com/blog/digital-account-opening-platform/).

### Why is the loss recorded in the wrong place?

Because a bust-out looks identical to a credit deterioration unless you connect the accounts involved.

If your institution charges off an account with no linkage analysis, the case enters credit loss statistics and the pattern is invisible. Institutions that start linking discover clusters: fifteen charge-offs across three products sharing devices, phone number stems, or funding accounts. That reclassification is often the first business case for the programme, because it moves a known cost from an unexplained bucket into a preventable one. Ask for a retrospective linkage analysis of last year's charge-offs before asking for budget.

> **Would your institution recognise a cluster of related charge-offs as one fraud case?**
>
> [Talk to Digiqt about a retrospective linkage analysis](https://digiqt.com/contact-us/)

## Which detection signals actually work?

Relationship anomalies first, then file and behavioural patterns, then bust-out precursors.

| Signal group | Examples | Strength |
|---|---|---|
| Shared attributes across identities | Same device, contact stem, address history, funding account, employer across unrelated identities | Very high |
| Application velocity in a cluster | Several applications from linked attributes within a short window | High |
| File characteristics | Thin or recently created credit presence, unusual identifier-to-age relationship, sparse history depth | Medium to high |
| Behavioural cultivation | Small balances, perfect repayment, no organic life events, low product engagement | Medium |
| Bust-out precursors | Simultaneous limit-seeking across products, utilisation stepping up together, contact detail changes | High |
| Contact reachability | Unreachable by phone, mail returns, no digital footprint consistent with claimed history | Medium |

### Why is data linkage the core technique?

Because a synthetic identity is unremarkable alone and obviously anomalous in relationship.

The whole method rests on that asymmetry. One identity sharing a device with another proves little. Twelve identities sharing three devices, two funding accounts, and a phone number pattern is not a coincidence, and no per-application score will ever see it. That is why graph representation matters, and why network approaches keep outperforming rules here. The BIS Innovation Hub's Project Aurora, reported in May 2023, found that privacy-enhancing technologies combined with network analysis across institutions detected potentially up to three times more complex schemes while reducing false positives by up to eighty percent compared with siloed, rules-based approaches. The reasoning and tooling behind that graph view is set out in this guide to [using graph databases to uncover fraud networks](https://digiqt.com/blog/graph-database-systemic-risk-analysis/).

### Which relationships belong in the graph?

Devices, contact details, addresses, funding instruments, employers, and application metadata.

Build edges from attributes a fraudster must reuse: devices and their identifiers, phone numbers and email patterns, addresses including historical ones, bank accounts used for funding or repayment, claimed employers, and application session metadata such as IP ranges and submission timing. Weight edges by discriminating power, since a shared corporate email domain means almost nothing while a shared device means a great deal. Then compute cluster-level features such as size, density, growth rate, and the share of members already in default, because those cluster features are what the model should consume rather than raw edges.

## How should entity resolution be built?

As a scored relationship graph kept deliberately separate from your customer master record.

Entity resolution for risk and entity resolution for customer mastering are different problems with different error costs, and conflating them causes real harm. Use deterministic rules for high-confidence identity matching in the master record, and use probabilistic scored linkage for the risk graph. A probabilistic link should never silently merge two real customers, because the consequences of a wrong merge, from misdirected statements to incorrect credit decisions, land on genuine people. The mastering side of this problem, including how duplicates arise in the first place, is covered in [solving duplicate customer records](https://digiqt.com/blog/credit-bureau-integration-architecture/).

### How do you prevent wrongly implicating real customers?

By requiring corroboration, keeping thresholds high for action, and retaining the specific evidence.

Households share addresses, families share devices, and small businesses share contact details, so a single shared attribute must never trigger action. Require multiple independent links plus at least one behavioural or file signal before a case is raised, keep the action threshold materially higher than the investigation threshold, and always store the exact evidence behind a score so a reviewer can see which links fired. Then track false positive outcomes by link type, since that is how you learn which attributes are noisy in your population rather than in a vendor's benchmark.

## How should machine learning be applied?

On graph and cluster features, with realistic handling of scarce and delayed labels.

The modelling problem here is unusual not because the algorithms are exotic but because the supervision is poor. Design around that rather than pretending otherwise.

### What labels do you actually have?

Very few confirmed cases, arriving months late, so start with weak labels and improve them.

Confirmed synthetic identity cases are rare and confirmation is slow, which rules out naive supervised learning at the start. Most programmes begin with weak labels: first-payment default combined with linkage anomalies, charge-offs within a cluster, or accounts unreachable at default. Treat those as proxies with known bias, be explicit about that bias in model documentation, and build a case management process that generates clean labels going forward, because in two years your label quality determines your model quality. That labelling and retraining discipline is the core of what this guide to [MLOps for regulated workloads](https://digiqt.com/blog/developer-velocity-regulated-banking/) describes.

### Which model families fit the problem?

Gradient-boosted models on engineered graph features first, graph neural networks once the data supports them.

Engineered cluster features fed to a well-tuned gradient-boosted model are usually the right starting point: they train on modest label volumes, they are explainable, and they capture most of the available signal. Graph neural networks earn their place at larger scale and where relationship structure carries information that hand-engineered features miss, which is where Project Aurora's network approach showed its advantage. Sequence them in that order rather than starting with the more sophisticated option, because a model nobody can explain and nobody can label properly will not survive its first credit committee review.

### How do you handle explainability and customer impact?

By preserving linkage evidence and treating any credit-affecting decision as one you must justify.

Declining an application or restricting a limit on the basis of a synthetic identity score affects a real person if the score is wrong, and it must be explainable in terms a regulator and a customer accept. Keep reason codes tied to specific evidence, never to a raw score, and review adverse outcomes as a standing process rather than on complaint. The governance framework for that sits in this guide to [model governance and explainability](https://digiqt.com/blog/model-risk-management-platform-sr-11-7/), and the same principles apply whether the model sits in underwriting or in fraud.

> **Can you show which specific links produced a synthetic identity score?**
>
> [Talk to Digiqt about explainable fraud model design](https://digiqt.com/contact-us/)

## Where in the lifecycle should detection run?

At onboarding, through early tenure, at every limit increase, and continuously for bust-out precursors.

| Lifecycle point | What to look for | Action available |
|---|---|---|
| Application | Cluster membership, velocity, file thinness | Decline, step up proofing, approve with lower limit |
| First 90 days | Behaviour inconsistent with claimed profile, unreachability | Restrict, verify, monitor |
| Limit increase request | Cluster growth, coordinated limit-seeking | Hold, require verification |
| Ongoing tenure | New links appearing to known clusters | Re-score, adjust limits |
| Pre-bust-out window | Utilisation stepping up across products, contact changes | Freeze limits, block cash access |
| Default | Retrospective linkage for reclassification | Recovery decisions, label generation |

The pre-bust-out window is where the money is saved. A cultivated identity is worth very little to a fraudster until it can draw everything at once, so detecting coordinated utilisation increases across a cluster in the weeks beforehand prevents the loss rather than merely explaining it afterwards. That means the graph must be scored continuously, not only at application, which is the single most common gap in existing programmes.

## What governance does this require?

Clear lawful basis for linkage, retention limits, access control, and defined handling of adverse outcomes.

Linking identities across products and channels means processing personal data for a purpose the customer did not directly request, so establish the lawful basis and document it before building. Keep the graph access-controlled and audited, since it is one of the most sensitive datasets in the bank. Set retention limits per attribute rather than keeping everything indefinitely. And define the process for a customer who disputes a decision, including how a link is reviewed and removed. Multi-jurisdiction operations add another layer, as set out in this guide to [data privacy compliance across jurisdictions](https://digiqt.com/blog/privacy-enhancing-technologies-finance/).

## How do you measure success when labels are scarce?

Through cluster-level outcomes, reclassified losses, prevented exposure, and precision on reviewed cases.

Report clusters identified and their eventual performance, which is a stronger measure than per-application accuracy. Track charge-offs reclassified from credit loss to fraud, since that quantifies the problem you were previously not measuring. Measure exposure prevented, meaning limits withheld or frozen on accounts that later showed bust-out behaviour elsewhere in the cluster. Watch precision on cases sent to review, because analyst time is your constraint. And track time from cluster formation to detection, since that interval is the fraudster's cultivation window and shortening it is the clearest sign the programme is maturing.

## How should delivery be phased?

Linkage first, then retrospective analysis, then scoring at application, then continuous cluster monitoring.

Build the linkage graph before any model, because everything depends on it and it delivers value immediately through investigation support. Run a retrospective analysis of past charge-offs next, which produces both the business case and your first labels. Then score at application using cluster features, with actions limited to step-up verification and lower initial limits rather than outright decline while precision is unproven. Then move to continuous cluster monitoring with bust-out detection, which is where losses are actually prevented. Cross-institution sharing comes last and multiplies the value of everything before it, for the reasons set out in [federated fraud intelligence sharing](https://digiqt.com/blog/federated-fraud-data-sharing/), and the behavioural side of the same problem connects to [authorised push payment fraud prevention](https://digiqt.com/blog/authorized-push-payment-fraud-prevention/) where mule accounts are frequently synthetic.

Synthetic identity fraud is the clearest example in banking of a problem invisible to per-transaction and per-application controls. It only becomes visible when you look at relationships, which means the investment is in data linkage and graph engineering rather than in another scoring model bolted onto the application flow.

## Frequently Asked Questions

### What is a synthetic identity?

A fabricated identity built from a mix of real and invented attributes, often a genuine identifier paired with an invented name and date of birth, cultivated until it looks like an ordinary customer.

### Why does synthetic identity fraud pass onboarding checks?

Because each attribute is individually verifiable. The identifier exists, the address is real, and the documents may be genuine, so checks that validate attributes separately find nothing wrong.

### Why is it usually recorded as credit loss rather than fraud?

Because the account performs normally, then defaults with no one to pursue. Without linkage analysis the case looks like an ordinary charge-off, which is why the problem is systematically understated.

### Why is data linkage the core detection technique?

Because a synthetic identity is normal in isolation and anomalous in relationship. Shared devices, contact details, addresses, and funding sources across supposedly unrelated identities are the strongest signal.

### What labels can you actually train on?

Very few confirmed cases, arriving late. Most programmes start with weak labels such as first-payment default combined with linkage anomalies, then improve labels as confirmed cases accumulate.

### What is a bust-out?

The moment a cultivated synthetic identity maximises every available credit line and disappears. Detection value is highest in the weeks before it, when utilisation and behaviour shift together.

### How do you avoid wrongly merging real customers?

Keep linkage separate from customer mastering. Use a scored relationship graph for risk decisions and never let a probabilistic link silently merge two real customer records.

### Does this need explainability?

Yes. Any decision affecting credit access must be explainable in terms a customer and a regulator accept, so preserve the specific linkage evidence behind every score.

## Sources

- [NIST SP 800-63A, Digital Identity Guidelines: Enrollment and Identity Proofing Requirements](https://pages.nist.gov/800-63-3/sp800-63a.html)
- [BIS Innovation Hub, Project Aurora](https://www.bis.org/about/bisih/topics/fmis/aurora.htm)

Posts tagged with#Fraud

Account Takeover Prevention Banking: Securing Digital Channels

Authorized Push Payment Fraud Prevention With Behavioral Signals

Behavioral Biometrics Banking: Device Intelligence in Mobile Apps

Federated Fraud Data Sharing Without Exposing Customer Data

Synthetic Identity Fraud Detection With ML and Data Linkage

Our Offices