Digital, Card, Instant Payment and Virtual Asset Red Flags

Digital channels change the economics of financial crime because customers, criminals and payment systems can all act in seconds. The speed does not make every digital transaction high risk, and it does not make post-event controls useless. It does mean that banks need to decide which signals must influence a transaction before execution, which can be analysed after settlement, and how findings from later investigations feed back into future prevention.

Three ideas are useful from the start. First, authentication and payment safety are related but different. A bank can correctly authenticate its genuine customer and still process a payment that the customer was deceived into making. Second, a single digital signal rarely proves criminal activity. A new device, a new beneficiary, unusual velocity or a transfer to a virtual-asset service provider can all be legitimate. Risk comes from combinations, context and change from an explainable baseline. Third, legal duties differ by jurisdiction, rail and product. Strong customer authentication in the EEA, the UK APP scam reimbursement regime, EU Verification of Payee and FATF standards for virtual assets are important examples, but none should be presented as a single global rule for every bank.

Digital-channel red flags spanning velocity, device change, beneficiary novelty, cards and virtual-asset touchpoints, with decision points before and after execution.

The practical objective is not to maximise the number of alerts. It is to identify the small set of events where additional friction, verification, restriction, investigation or post-event recovery work is justified, while allowing normal customer activity to continue with minimal disruption.

Why this topic belongs inside financial crime, not only fraud

Card fraud, account takeover and authorised push payment scams are often owned operationally by fraud teams. AML teams may focus on proceeds after the theft, especially mule accounts, pass-through behaviour and movement into cash, crypto or other banks. Sanctions teams may become involved where designated parties, restricted jurisdictions or relevant ownership links appear. Payment operations may handle recalls, returns and beneficiary-bank outreach. Customer protection teams may own reimbursement and complaints. The same event can therefore create several control questions at different times.

A useful operating model separates the questions. Fraud controls ask whether the customer or payment is being manipulated or taken over. AML controls ask whether an account or transaction is handling criminal proceeds or otherwise creates suspicion under the applicable legal framework. Sanctions controls ask whether a prohibition, asset-freeze requirement or other restriction applies. Payment operations ask what the rail still allows the bank to do. Those questions should share data without collapsing into one generic risk flag.

FATF's February 2026 paper on cyber-enabled fraud is helpful because it treats fraud as a major source of illicit proceeds and emphasises the need to connect prevention, detection, investigation, information sharing and asset recovery. It does not turn every scam signal into an AML conclusion. The bank still needs evidence, local reporting rules and a clear handoff between fraud and financial-crime functions.

A digital red flag is a prompt to ask a better question

A red flag is not a verdict. The value of a signal depends on what else the bank knows. A new device followed by the customer's normal salary payment is different from a new device followed by a password reset, creation of a new beneficiary and an unusually large instant payment. A crypto exchange payment from a customer who has invested through the same regulated provider for years is different from a first-ever high-value transfer to an offshore platform after a recent account takeover signal.

The strongest digital detection therefore combines several categories of evidence: customer profile, device and session data, transaction history, beneficiary history, counterparty intelligence, payment-rail attributes, fraud outcomes, external intelligence and where permitted, network relationships across accounts. The decision engine should preserve the individual signals so investigators can explain why a case was created instead of presenting an opaque aggregate score as if it were self-explanatory.

Authorised payment scams and the authentication boundary

Social engineering creates a difficult situation because the payer may be genuine, the device may be trusted and the authentication event may be completely valid. The weakness is not always in proving who authorised the payment. It may be in understanding who is receiving it and why.

The EBA and ECB's 2025 payment-fraud report is useful evidence of this distinction in the EEA. Strong customer authentication continued to reduce fraud for the types of attacks it was designed to address, particularly card fraud, while manipulation of legitimate payers remained a growing concern for credit transfers. That is why stronger authentication alone cannot be the entire response to scams.

Banks commonly combine authentication with payment-specific measures such as beneficiary verification, contextual warnings, transaction limits, behavioural monitoring, device intelligence and beneficiary-risk models. Whether a bank may delay, decline, hold or otherwise intervene depends on the relevant law, scheme rules, contract and local policy. A learning chapter should not imply that every institution has a universal legal duty to impose a cooling-off period whenever an algorithm predicts a scam.

Reimbursement is also jurisdiction-specific. In the United Kingdom, the Payment Systems Regulator's mandatory APP scam reimbursement framework came into effect on 7 October 2024 for in-scope Faster Payments and CHAPS payments, with detailed scope, time limits, exceptions and a reimbursement cap. That framework is an important case study, not a global liability model. Other jurisdictions allocate loss differently, and internal bank policy may go beyond legal minimums.

Verification of payee and name-account checks

Name-account checking can reduce misdirected payments and some impersonation scams, but the design and legal status vary. In the EU, Regulation (EU) 2024/886 requires payment service providers in scope to offer Verification of Payee for euro credit transfers according to its implementation timetable. The payer is informed whether the account identifier and intended payee name match, closely match, do not match or return another result. The payer can then decide how to proceed, subject to the applicable framework.

Other markets use different products and terminology, including Confirmation of Payee in the United Kingdom. A global bank should therefore model the capability generically and keep scheme-specific response codes separate. The decision record should capture the name submitted by the payer, account identifier, verification response, any close-match name returned where permitted, warning shown, customer action and final payment decision.

Verification is not proof of legitimacy. A mule account can be held in the exact name supplied by a fraudster and still return a match. A mismatch can also be innocent because of trading names, joint accounts, transliteration, abbreviations or legacy account records. The control is strongest when combined with beneficiary history and transaction context.

Velocity: useful evidence when calibrated properly

Velocity is one of the most useful digital signals because criminal activity often compresses actions into short periods. Examples include repeated low-value card probes, rapid creation of multiple beneficiaries, several outbound transfers after an account takeover, or funds arriving and leaving a suspected mule account almost immediately.

The mistake is to treat speed itself as suspicion. Corporate treasury customers, marketplaces, payroll processors and some retail users can generate high transaction volumes legitimately. Thresholds need segmentation, time-zone awareness and product context. A daily rule designed for a personal current account should not be copied to a merchant-acquiring settlement account.

Useful velocity features include transaction count, value, number of new beneficiaries, time between receipt and onward transfer, failed-authentication events, number of devices, number of counterparties and network synchronisation across apparently unrelated accounts. Model governance should show how each feature is derived, which source systems feed it, the lookback window and how late or duplicated events are handled.

Velocity evidence combining burst activity, time-of-day context and coordinated multi-account behaviour rather than relying on one amount threshold.

A BA or tester should challenge rules that say only "more than X transactions in Y minutes" without customer segmentation, exception logic, scenario rationale and evidence of both positive and negative testing.

Device change and session risk

Device information can help distinguish normal customer behaviour from account takeover, but it is not identity proof by itself. A genuine customer may replace a phone, travel, reset an app or use accessibility tools. Criminals may use emulators, remote-access tools, device farms, anonymisation services or compromised genuine devices. The useful question is how the device event fits with the rest of the session.

Signals can include device binding, app integrity, operating-system version, IP and network attributes, SIM or phone-number change, recent credential reset, remote-access indicators, impossible or implausible travel patterns, new biometric enrolment and changes in interaction behaviour. Banks should avoid making deterministic conclusions from any one attribute because commercial device-intelligence data can be incomplete or wrong.

Biometrics also need careful language. They can strengthen authentication but are probabilistic and have privacy, accessibility and spoofing considerations. NIST SP 800-63B is a useful technical benchmark, although it is a US federal digital-identity standard rather than a universal banking law. The current NIST guidance treats biometric comparison as part of multi-factor authentication rather than a standalone authenticator, prefers local comparison where practicable, requires an alternative non-biometric option in its own scope and contains requirements for presentation-attack detection and biometric performance. Banks should map those principles against the actual law and standards that apply to their market and product.

Device-risk decisioning combines device change, session context, behavioural continuity and transaction risk before deciding whether additional authentication or review is justified.

New beneficiaries and payee intelligence

A new beneficiary deserves attention because there is little relationship history, not because new payees are inherently suspicious. Useful questions include whether the customer has paid the counterparty before through another account, whether the payee is newly opened or recently associated with fraud, whether the payment purpose fits the customer's profile, and whether the amount or urgency differs from normal behaviour.

Beneficiary intelligence can include confirmed fraud reports, mule-account findings, previous payment outcomes, account age where lawfully available, return or recall history, known scam reports, network links and cross-institution intelligence-sharing arrangements. Governance is essential. A suspected mule should not be converted into a permanent blacklist entry without defined evidence thresholds, review dates, access controls and a process for correction or removal when the evidence changes.

The receiving institution also has a role. Scam prevention is weaker when the sending bank carries all the intelligence while the beneficiary bank sees repeated inbound victim payments and fast onward dispersal. The exact information-sharing mechanism varies by jurisdiction, but operational design should enable relevant intelligence to reach the team capable of acting on the receiving account.

Card red flags are different from account-transfer red flags

Card controls operate in an authorisation and scheme environment that differs from account-to-account transfers. Card testing often starts with low-value transactions or repeated authorisation attempts to determine whether stolen credentials are usable. Card-not-present fraud can combine compromised credentials with device changes, unusual merchant categories and geographies. Account takeover can change delivery addresses, digital-wallet provisioning or spending patterns.

Acquirers and issuers also see different risks. An issuer focuses on whether the cardholder transaction is genuine. An acquirer must consider merchant fraud, transaction laundering, collusive refund activity, abnormal processing volumes and misrepresented merchant activity. Chargeback data can reveal patterns, but it is not a substitute for transaction monitoring because losses may become visible only after the criminal activity has already scaled.

3-D Secure and scheme liability-shift rules must be described as scheme and implementation specific. Authentication results, exemptions, merchant configuration and issuer decisions affect liability under the relevant card-scheme rules and local law. The learning point is to preserve authentication and authorisation data well enough to reconstruct the decision, not to imply a single universal liability rule across all cards.

Instant payments: prevention is critical, but recovery still matters

Instant payment systems compress the decision window, so controls that genuinely need to affect execution must operate within the rail's timing requirements. That makes low-latency beneficiary checks, fraud scoring, authentication and transaction decisioning important. It does not mean that post-event work is pointless. Banks may still use scheme recall or return procedures, contact the receiving institution, freeze or restrict funds where legally permitted, support law-enforcement action, investigate related accounts, reimburse customers where required, and feed intelligence back into future controls.

Sanctions treatment is a good example of why global language must be precise. A bank should not assume that every instant payment worldwide requires identical per-transaction sanctions screening. Under the EU Instant Payments Regulation, PSPs offering instant credit transfers have a specific obligation to verify periodically, and at least daily, whether their payment service users are persons or entities subject to targeted financial restrictive measures. Banks may have other screening duties under other laws or policies, but those need to be identified separately.

Real-time architecture should therefore start from an obligation map: which checks are legally or contractually required before execution, which are risk-based controls chosen by the bank, which data are available within the latency budget, and what happens if a dependency is unavailable. Fallback behaviour must be agreed in advance with compliance, legal, scheme and operational owners. There is no safe universal rule that every service outage should cause every instant payment to be rejected or released.

Virtual assets: risk-based scrutiny, not automatic suspicion

Payments to or from virtual-asset businesses require a risk-based view. FATF Recommendation 15 and its guidance apply AML/CFT standards to virtual assets and VASPs, but implementation differs across jurisdictions. FATF's July 2026 targeted update found continued progress in regulation and Travel Rule implementation while also identifying material gaps in licensing, supervision and enforcement. FATF's 2026 work also highlighted risks involving stablecoins, peer-to-peer transactions through unhosted wallets, offshore VASPs and DeFi.

For a bank, the first question is what it can actually observe. A bank may see a transfer to a known exchange, customer narrative, beneficiary account, amount and timing. It may not see the customer's later blockchain transaction unless additional data or lawful analytics are available. Conversely, a bank serving a VASP directly may have much richer information and stronger due-diligence expectations.

Useful risk factors include the VASP's jurisdiction and regulatory status, whether the relationship is direct or through an omnibus account, transaction size and frequency, source of funds, customer profile, exposure to high-risk services, and credible blockchain analytics where available. A first-ever crypto payment is not automatically grounds for enhanced due diligence. It is one factor that may justify additional questions when combined with unusual value, scam indicators, opaque counterparties or other risk signals.

Blockchain analytics can assist investigation but should not be treated as infallible. Address attribution can change, cross-chain activity can complicate tracing, and vendor risk scores need explainability and corroboration. Investigators should preserve the underlying transaction hashes, addresses, timestamps, attribution source and confidence level rather than recording only a red or green score.

Virtual-asset off-ramp analysis separates what the bank directly knows from what may be inferred or obtained through VASP and blockchain data, with risk-based escalation.

Cross-channel behaviour is where many cases become clear

Criminal value can move from a compromised digital session to an instant-payment beneficiary, then to another bank, a card, cash withdrawal or virtual-asset platform. If each channel owns a separate alert queue, the bank may close several apparently weak alerts that would form a strong case when viewed together.

A useful investigation timeline links customer, account, beneficiary, device, session, payment, card, merchant and VASP identifiers with timestamps. Entity resolution must be transparent: investigators should know whether two devices are definitely the same, likely the same, or merely share an IP address. Data lineage matters because a mistaken merge can create an apparently sophisticated network that does not exist.

Cross-channel analytics should therefore be measured on incremental value. If a new network model generates the same cases already detected by existing rules, the extra complexity may not be justified. If it discovers coordinated campaigns earlier, that benefit should be evidenced through back-testing and case outcomes.

Alert, case and investigation outcomes

An alert should answer a narrow question: what signal fired, what data support it, and why is the event outside an expected pattern? Triage then determines whether the signal can be explained quickly or needs a case. A case should bring together the customer profile, session and device history, relevant transactions, beneficiaries, fraud reports, external intelligence and previous investigations.

Possible outcomes depend on the facts and jurisdiction. They can include closing the alert with a documented explanation, adding enhanced monitoring, contacting the customer, changing authentication requirements, restricting a payment or account where permitted, filing a suspicious activity report or equivalent where the legal threshold is met, submitting fraud intelligence, initiating recovery activity, escalating sanctions concerns, or exiting a relationship under governed processes. There is no universal sequence in which every digital alert becomes an AML report.

Investigators should separate known facts from hypotheses. "The customer used a new device at 14:03" is a fact. "The device belongs to a fraudster" is a conclusion that needs evidence. "The payment went to a newly opened beneficiary account" may be a fact if the data are available. "The beneficiary is a mule" requires a defensible basis.

Data and system touchpoints

A mature digital-control design typically needs data from several layers: digital channel, identity and authentication, device intelligence, payment orchestration, card authorisation, customer master, KYC profile, beneficiary or payee service, fraud engine, AML monitoring, sanctions screening, case management, customer-service systems and external intelligence providers. Not every bank has all of these components, and the architecture can be centralised or distributed.

The BA challenge is to define the data contract clearly. Device identifiers need source and persistence rules. Beneficiary identifiers need normalisation. Payment timestamps need a common time standard. Reversals and retries need unique event IDs. Fraud outcomes should be fed back to model and rule tuning without contaminating labels with cases that were merely suspected. Personal and biometric data need access, retention and purpose controls aligned to applicable privacy law.

The architecture also needs failure behaviour. What happens if a payee-verification service is unavailable? What if the fraud engine exceeds the rail's latency budget? What if the case platform is down but the payment engine is healthy? These are business-control questions as much as technical ones because each fallback changes customer, fraud and compliance risk.

Roles and governance

Product owns the customer journey and commercial trade-offs. Fraud teams own or co-own scam and account-takeover controls. AML teams own suspicious-activity assessment under local policy and law. Sanctions specialists own sanctions applicability and disposition. Payment operations understand what the rail can technically do after a payment is initiated or settled. Technology teams own implementation and resilience. Data science or analytics teams may own models, but model owners should not be the only people able to explain a decision.

Second-line compliance should challenge whether financial-crime obligations are correctly translated into controls. Internal audit provides independent assurance. Legal teams are important where reimbursement, account restriction, privacy, information sharing or sanctions scope is uncertain. Customer-support teams need playbooks because the quality of the customer conversation can determine whether a scam is interrupted or compounded.

Governance metrics should include more than alert volume. Useful measures include prevented loss, confirmed fraud conversion, false-positive burden, customer abandonment, time to contact, recall or recovery success, mule-account identification, beneficiary-risk precision, model drift, service latency and complaint outcomes. Metrics should be segmented so a good portfolio average does not hide a weak channel or vulnerable customer group.

Mini case: genuine customer, dangerous beneficiary

A retail customer who has banked with the institution for six years logs in from the same mobile device used for months. Authentication succeeds normally. The customer then adds a new beneficiary and initiates a high-value instant payment described as an investment. The amount is unusual but affordable. The customer has no prior payments to virtual-asset businesses.

The initial fraud score rises because of the new beneficiary, amount and first-time investment context, but there is no account-takeover evidence. Verification of payee, where available for the rail, confirms that the beneficiary name matches the account. That reduces misdirection risk but does not establish legitimacy. The receiving account has recently received several payments reported by other customers as scam-related. A beneficiary-risk service therefore produces a high-risk result.

The bank applies the intervention permitted by its local framework: a targeted warning and additional confirmation process. The customer initially insists the investment is legitimate but, during the conversation, reveals that a supposed adviser is remotely guiding the payment and has promised guaranteed returns. The payment is not executed. Fraud operations record the scam indicators and beneficiary intelligence. AML reviews whether the receiving account information should be shared or reported under the applicable framework. No SAR or STR is filed automatically merely because the payment was stopped; the reporting decision is made under the relevant legal threshold and available facts.

Now change one fact: assume the payment had already settled before the receiving-account intelligence arrived. The control objective shifts. Operations seek recovery through the rail and beneficiary bank, fraud teams support the customer and any reimbursement process, investigators look for related beneficiaries and devices, and the confirmed outcome feeds back into future beneficiary-risk controls. The same event therefore illustrates both pre-execution prevention and post-event investigation.

What good requirements look like

Good requirements describe decision points, evidence and outcomes rather than simply demanding "real-time fraud monitoring". They state which events are available before authorisation, which service owns each signal, the maximum response time, what happens when data are missing, which decisions are automated, when human review is required, how customer communication is generated and what evidence is stored.

Testing should include positive cases, legitimate high-risk-looking cases, boundary conditions and failure modes. A new phone with normal behaviour should not automatically fail. A first payment to a genuine new supplier should be allowed when evidence supports it. A simulated mule network should be detected. A payee-verification outage should follow documented fallback. A sanctions-service failure should follow the rule for the specific jurisdiction and rail rather than a generic test assumption.

The strongest test pack connects front-end behaviour to downstream evidence. It verifies not only that a transaction was challenged or declined, but also that the case contains the right reason codes, timestamps, data lineage and customer-message record. That is what allows operations, investigators, auditors and regulators to reconstruct the decision later.

Key takeaways

Digital financial crime is not one problem. It is an interaction between identity, customer behaviour, payment speed, beneficiary risk, card mechanics, scam manipulation, virtual-asset exposure and the institution's ability to connect data across channels.

Authentication can prove that the genuine customer acted without proving that the payment purpose or beneficiary was safe. Velocity, device change and new payees are useful signals only when calibrated to context. Instant payments make pre-execution controls especially important, but recovery, investigation and intelligence feedback remain valuable after settlement. Virtual-asset activity should be treated through risk-based controls rather than automatic suspicion. Above all, legal and scheme obligations must be mapped by jurisdiction instead of being inferred from a control practice used in one market.

References and further reading

Operational deep dive: card, authentication and merchant-side evidence

The base chapter separates authentication from payment safety and distinguishes card risks from account-to-account transfer risks. This deep dive goes further into the evidence a bank needs when cards, digital wallets and merchant acquiring generate the alert. The aim is not to teach one scheme's rules as universal. Card liability, authentication requirements, chargeback windows, exemptions and evidence standards vary by jurisdiction, product and scheme, so operational procedures must point to the rule set that actually governs the transaction.

Card testing as a sequence, not a single transaction

Stolen card credentials are often tested before they are exploited. A low-value e-commerce authorisation can be completely legitimate in isolation, but a sequence of small authorisations across unrelated merchants, rapid decline-and-retry behaviour, changes in merchant geography or a sudden transition from low-value probes to larger purchases can form a stronger pattern. Detection therefore needs event sequencing rather than a collection of independent amount rules.

Useful features include the number of authorisation attempts in a short interval, merchant diversity, decline reason, card-present versus card-not-present channel, device or browser fingerprint where available, token status, merchant category, country, amount progression and whether the same device is presenting several unrelated cards. The issuer and acquirer will see different parts of that picture. An issuer can compare activity with the cardholder's history; an acquirer can compare merchants, devices and settlement behaviour across its portfolio.

The control should be measured for both fraud capture and customer harm. A rule that stops every unusual low-value authorisation may appear effective because loss declines, but it can also create unnecessary declines and calls. Back-testing should include genuine subscription checks, transport pre-authorisations, hotel or fuel deposits and other normal low-value patterns so the model learns the difference between testing behaviour and ordinary commerce.

3-D Secure and strong customer authentication

3-D Secure is a card authentication framework whose operational effect depends on the scheme version, merchant and issuer implementation, transaction type and relevant regulation. In the EEA, strong customer authentication requirements under PSD2 and related technical standards influence many electronic payments, but the detailed treatment of exemptions and liability cannot be assumed to apply identically outside that framework.

A good case record preserves the authentication outcome rather than simply recording 3DS=yes. Useful evidence includes protocol version, challenge or frictionless path, exemption or out-of-scope indicator where applicable, authentication value, issuer decision, merchant data, authorisation response and timestamps. That allows a later reviewer to understand what protection was used and whether the transaction followed the path expected by the applicable scheme and local rules.

Authentication success is not proof that a purchase is legitimate. A genuine cardholder may be socially engineered, a criminal may control the session after a credential compromise, or the merchant itself may be problematic. Authentication is one layer of evidence within the wider fraud decision.

Tokenisation and digital-wallet provisioning

Network and device tokens reduce exposure of the underlying card number by replacing it with a restricted credential. That can materially reduce some types of credential reuse, but token provisioning becomes an important control point. If a criminal can enrol a stolen card into a wallet, later tokenised transactions may look stronger than the original provisioning decision deserved.

Provisioning controls can consider customer authentication, device binding, previous device history, recent credential resets, SIM or phone-number changes, token requestor, risk scores supplied through the card network and unusual attempts across multiple cards. Banks should preserve enough provisioning evidence to investigate how a token was created and whether the device later changed ownership or risk state.

Token risk is also a useful example of why architecture matters. The card processor may know the token, the mobile channel may know the device, and the fraud engine may know the customer's recent login history. If those identifiers cannot be connected, each system can appear normal while the combined story shows takeover.

Merchant acquiring and transaction laundering

Acquirers need controls that look beyond individual cardholders. A merchant can be onboarded for one business model and then process transactions for another, hide prohibited or undisclosed activity behind a legitimate merchant descriptor, or collude with customers in refund and chargeback abuse. The relevant evidence sits across KYB, website or application review, merchant category, settlement account, transaction profile, refund behaviour, chargebacks and linked merchant entities.

Transaction laundering can be difficult to prove from payment data alone. A mismatch between stated business type and observed activity is a reason to investigate, not automatic evidence of laundering. Review may involve merchant websites, invoices, delivery records, customer complaints, domain ownership, fulfilment information and changes in beneficial ownership or settlement instructions. The acquirer should keep the basis for any restriction or termination decision because legitimate businesses can also pivot, add products or experience seasonal spikes.

New merchants deserve proportionate attention because the bank has less history, but age alone should not be a risk verdict. Strong onboarding and early-life monitoring work together: the first provides a baseline, the second tests whether the business behaves as represented.

Disputes, friendly fraud and forensic evidence

Disputes are valuable intelligence but they are not all fraud and not all fraud is visible through disputes. A customer may genuinely not recognise a descriptor, a merchant may fail to deliver, a family member may have used a card, or a criminal may have made the purchase. Organised refund abuse and so-called friendly fraud add further complexity.

A defensible review looks at device continuity, delivery evidence, IP and session information where lawfully available, prior dispute history, merchant patterns, refund timing, account relationships and whether apparently unrelated customers share addresses or devices. The goal is to distinguish customer protection from abuse without treating every repeat complainant as dishonest.

Chargeback evidence must also be handled within the governing scheme's deadlines and formats. Operations teams need a clear separation between the financial-crime case, the card-dispute process and any customer complaint so one workflow does not accidentally close or overwrite evidence needed by another.

Behavioural biometrics and continuous signals

Behavioural signals such as typing rhythm, navigation path or touch interaction can help identify a session that no longer behaves like the usual customer. They should be treated as probabilistic evidence. Accessibility tools, injury, age, travel, new devices and software changes can legitimately alter interaction patterns.

Where banks use behavioural biometrics or other biometric technologies, privacy, fairness, security and accessibility requirements need explicit ownership. NIST SP 800-63B is a useful technical reference for authentication design, but it is not a universal banking rule. Local data-protection law and the bank's actual authentication obligations remain the governing framework.

Testing should include demographic and accessibility considerations, spoofing and presentation attacks where relevant, device replacement, genuine customer behaviour under stress and account takeover simulations. A control should demonstrate that it improves security without systematically excluding customers who interact differently from the training population.

What an investigator needs from the card stack

A case should be able to reconstruct the sequence: authentication or wallet provisioning, authorisation requests, merchant and device attributes, decision scores, declines or approvals, settlement, dispute or fraud report and any later card or account restriction. Timestamps and unique identifiers are essential because card systems often produce several events for what a customer experiences as one purchase.

For business analysts and architects, that means mapping token, PAN surrogate, merchant ID, device ID, customer ID, authorisation ID, network reference, dispute ID and case ID without exposing sensitive card data unnecessarily. For testers, it means proving that retries, reversals, partial approvals and late-arriving fraud outcomes do not create duplicate cases or break sequence detection.

The learning point is simple: card fraud controls become much stronger when the bank can see the transaction as a lifecycle rather than a single authorisation result.

Advanced practice: instant payments, beneficiary intelligence and virtual-asset controls

Digital financial-crime control is hardest where the decision window is short and the evidence is distributed across systems. Instant payments illustrate the problem clearly: some checks must influence execution within the rail's timing rules, while other analysis can only happen after settlement. Virtual-asset touchpoints create a related challenge because the bank may see only the fiat edge of a longer value chain. Good architecture distinguishes what the institution knows in real time, what it can enrich later and what it cannot reasonably infer.

Build the real-time decision path from obligations, not assumptions

The first design step is an obligation map. For each jurisdiction and payment rail, identify which checks are required before execution by law or scheme rules, which are bank risk controls, which can happen after the event and which require a human decision. This prevents teams from importing a control used in one market into another and calling it a regulatory requirement.

The EU Instant Payments Regulation provides a useful example. It introduced Verification of Payee and a specific approach to targeted financial restrictive measures for PSPs offering instant credit transfers. That approach should not be generalised into a statement that every instant payment in every jurisdiction must undergo identical transaction-by-transaction sanctions screening. A global implementation needs a rule matrix by legal entity, currency, rail and applicable sanctions framework.

Once obligations are clear, architecture can allocate latency. Fast deterministic checks may run synchronously. More expensive analytics can run in parallel where dependencies allow. Some enrichment can be asynchronous and feed future beneficiary or customer risk. The decision record should identify which checks actually completed before execution and which arrived later.

Beneficiary intelligence as a reusable bank capability

A payment can be genuine from the payer's perspective and still be dangerous because the receiving account is controlled by a scammer or mule. Beneficiary intelligence addresses that gap by building a history of receiving accounts, not only sending customers.

Useful evidence can include confirmed fraud reports, previous recalls and returns, account age where lawfully available, payment velocity, concentration of first-time payers, rapid onward movement, shared devices or identifiers, links to previously confirmed mule networks and cross-bank intelligence received through lawful sharing arrangements. The design should preserve evidence provenance and confidence. A beneficiary reported by one victim is not the same as a beneficiary confirmed through multiple independent cases.

Governance is as important as the model. Listing criteria, expiry, review, correction and access rights should be defined before a blacklist or high-risk payee service is used for automated decisions. A stale or weakly evidenced list can create customer harm at scale. Where consortium data are used, the bank needs to know what the contributor means by terms such as confirmed mule, suspected scam or high risk rather than assuming all participants apply the same evidence threshold.

Real-time resilience and fallback

Real-time controls depend on services: authentication, payee verification, fraud scoring, sanctions or other screening, customer profile, beneficiary intelligence and sometimes external providers. A service failure creates both fraud risk and operational risk.

Fallback design should be explicit and jurisdiction-aware. Options can include a locally cached check, reduced-scope decisioning, queueing where the rail allows it, customer retry, manual intervention for limited cases or rejection where required by the governing framework. There is no safe universal fallback for all payments. The correct behaviour depends on the legal obligation, scheme timing, customer contract and the risk represented by the missing service.

Testing should simulate partial and total outages, slow responses, stale caches and contradictory results. It should also test recovery: whether queued or retried transactions are duplicated, whether customer messages remain accurate, and whether evidence shows which control version was active at the time.

Measure tail latency, not only averages

A real-time control can look healthy on an average dashboard while failing during the slowest one or five per cent of transactions. Those are often the moments when infrastructure is under pressure and fraud traffic may also be elevated. Performance measurement should therefore use percentiles and peak-load scenarios, not only mean latency.

For each control, architects should know the allowed budget, normal and stressed response time, dependency timeout and failure action. Product owners should understand the trade-off: adding another enrichment may improve detection but can also increase false declines or push the journey beyond the rail's execution window. The correct decision is evidence-based, not simply more checks are safer.

Post-event controls still have real value

Settlement does not end the control lifecycle. A bank may still attempt recall or return through the scheme, contact the beneficiary institution, restrict remaining funds where legally permitted, identify linked accounts, support law enforcement, assess reimbursement, report suspicious activity where the local threshold is met and feed confirmed intelligence back into pre-execution controls.

This feedback loop matters. A beneficiary that looked normal on the first victim payment may become clearly risky after several reports. The system should update future risk promptly without rewriting history: investigators need to know what information was available at the original decision time and what became known only later.

VASP due diligence depends on the bank's relationship

Virtual-asset risk looks very different when a retail customer pays a VASP versus when the VASP itself is the bank's customer. For a direct VASP relationship, due diligence may examine licensing or registration, ownership, geographic footprint, AML/CFT programme, Travel Rule implementation, customer base, products, exposure to high-risk services, sanctions controls and the quality of transaction monitoring. The depth should reflect the relationship and applicable law.

For a retail customer's transfer to an exchange, the bank often has much less information. It may know the beneficiary account, exchange identity, jurisdiction, amount and customer's previous behaviour. It should not pretend to know the ultimate blockchain destination unless that information is actually available. That distinction should be explicit in system design and investigator training.

FATF's 2026 virtual-asset updates are useful current references because they highlight continuing implementation gaps across jurisdictions and risks linked to stablecoins, unhosted wallets, offshore VASPs and DeFi. They support a risk-based approach rather than a blanket assumption that all virtual-asset activity is suspicious.

Blockchain analytics: evidence with confidence, not an oracle

Commercial blockchain analytics can identify exposure to known addresses, services and transaction patterns, but the output is an analytic judgement built on attribution data. Investigators need the underlying address, transaction hash, chain, timestamp, path and confidence or methodology where available. A high-risk score without explainable evidence should not become an unchallengeable legal conclusion.

Cross-chain bridges, mixers, privacy-enhancing technologies and rapid movement can make tracing more difficult. Difficulty itself is not proof of criminal purpose. The investigator should combine blockchain information with customer profile, source of funds, VASP information, transaction history and any external intelligence.

Data retention also matters. If a vendor later changes an address attribution, the bank may need to reconstruct the score and evidence that existed when the original decision was made. Versioning and auditability are therefore control requirements, not optional technical detail.

Cross-channel fusion without creating an opaque super-score

A criminal campaign may touch a card, digital login, instant transfer and crypto platform in one day. Connecting those events can reveal risk earlier than separate channel queues. The architecture should use shared identifiers and timelines while keeping the contributing signals visible.

Entity resolution needs confidence levels. Two sessions using the same IP address are not necessarily the same person. Two customers sharing a device may be family members, employees or evidence of a fraud network. Network analytics should make those relationships inspectable so investigators can distinguish a strong link from a weak association.

A practical fusion layer can provide a customer and counterparty timeline, related accounts, device history, payment paths and prior confirmed outcomes. It should not hide all evidence behind one model score that case reviewers cannot explain.

Advanced testing and assurance

Positive tests should include account takeover, authorised scam, mule receiving account, card-testing sequence and risky VASP scenarios. Negative tests should include legitimate device upgrades, high-volume businesses, first-time genuine suppliers, normal investment activity and customers using accessibility tools. Boundary tests should change one fact at a time to prove the system responds proportionately.

Failure testing should cover external-service outages, late intelligence, duplicate events, clock skew, partial data, model rollback and rule-version changes. A mature test should answer not only whether a transaction was stopped, but whether the resulting case contains the correct evidence, customer communication, timestamps and control version.

The strongest assurance question is whether the institution can reconstruct why the decision made sense with the information available at that moment. That is the standard that connects technology, operations, compliance and audit.

Practice close: requirements, acceptance criteria and control testing

This section converts the chapter into delivery artefacts. Digital financial-crime controls fail surprisingly often because requirements describe a tool rather than a decision. Statements such as implement device monitoring, screen instant payments in real time or add crypto alerts are too vague for architecture, testing, operations or audit. A stronger requirement identifies the event, evidence, decision owner, timing, fallback and record that proves what happened.

Requirements for velocity and behavioural monitoring

Velocity requirements should define the population and time window. A useful story might specify that retail instant-payment activity is evaluated for a combination of newly created beneficiaries, transaction count, value, recent inbound funds and device changes over several configurable windows. It should also state how business accounts or other high-volume segments are handled and how the model treats retries, reversals and duplicate events.

Behavioural requirements should identify what the bank actually captures. If device intelligence is supplied by a third party, the requirement should specify the attributes consumed, freshness, confidence and behaviour when the service cannot return a result. If behavioural biometrics are used, privacy, fairness, retention and accessibility requirements need to be included rather than left to implementation teams after the model is built.

An acceptance criterion should prove the intended outcome. For example, a simulated takeover with a new device, credential reset and unusual beneficiary should produce a defined risk response, while a normal device upgrade followed by routine activity should not be treated as takeover solely because the device identifier changed.

Requirements for beneficiary intelligence

Beneficiary-risk requirements need an evidence model. The system should distinguish a payee that is merely new, a payee associated with one unconfirmed report, a payee linked to several confirmed fraud outcomes and a payee subject to an externally supplied high-confidence alert. These categories should not be hidden behind one binary field.

Requirements should cover effective date, source, confidence, expiry, review and removal. If a receiving account was flagged after a payment settled, the case should show that the flag did not exist at decision time. If the intelligence is later corrected, the system should retain the historical record needed for audit while preventing the stale classification from driving new decisions.

Where information comes from a consortium or another institution, define the legal basis, permitted purpose and data-quality expectations. The receiving system should know whether confirmed mule means an internal investigation outcome, a customer fraud report, law-enforcement information or another participant's risk label.

Payee verification acceptance criteria

Payee-verification functionality should be tested against the actual service and jurisdiction. Test match, close match, no match, unavailable and unsupported responses. Test personal and business names, joint accounts, abbreviations, diacritics and transliteration where relevant. Verify what is shown to the payer and what evidence is stored.

A payee match must not be translated into safe beneficiary=true. A mismatch must not automatically mean fraud. Acceptance tests should prove that the verification result remains one input to the payment decision, with other risk signals still visible.

For EU implementations subject to the Instant Payments Regulation, requirements should be traceable to the relevant Verification of Payee obligations and implementation dates. Other markets should reference their own scheme or legal framework rather than reusing EU terminology as if it were universal.

Instant-payment latency and failure testing

A real-time control needs performance criteria as well as functional criteria. Measure the end-to-end payment decision at realistic load and record the contribution of major dependencies. Use percentile measurements so occasional slow responses are visible. Test the combination of peak legitimate traffic and elevated fraud alerts rather than separate laboratory scenarios that underestimate operational stress.

Failure tests should cover an unavailable beneficiary service, delayed fraud engine, stale sanctions data, network interruption, retry after timeout and recovery after service restoration. Expected outcomes must come from the obligation map for the specific rail and jurisdiction. The test should not assume a generic fail open or fail closed rule.

Verify customer messaging during degraded service. A technically correct fallback can still create poor outcomes if the application tells a customer the beneficiary is safe when verification did not occur, or if repeated retries create duplicate transfers.

Card and digital-wallet testing

Card tests should include low-value credential testing followed by larger exploitation, repeated declines, merchant diversity, genuine small-value authorisations and legitimate subscription activity. Token tests should include new wallet provisioning, device replacement, re-provisioning after card replacement and attempted provisioning from a risky device.

For 3-D Secure or other card-authentication flows, verify the data needed by the relevant scheme and local regulation: protocol path, challenge result, exemption or out-of-scope treatment where applicable, authorisation decision and evidence retention. Do not encode a generic global liability outcome into the test unless the scheme rule and jurisdiction support it.

Acquirer tests should include a merchant whose volume legitimately increases, a merchant whose activity no longer fits the onboarded business, unusual refund patterns and linked merchants sharing settlement or device characteristics. The goal is to prove the control distinguishes unexplained change from explainable growth.

Virtual-asset and VASP test design

Virtual-asset tests should separate a retail customer's payment to a VASP from the bank's direct relationship with a VASP. For retail scenarios, test established exchange use, first-time but explainable investment, scam-related payment, unusual high-value transfer and return of funds from a VASP. Do not make first-time crypto activity automatically fail unless that is justified by the institution's approved risk framework.

For VASP customers, test licensing or registration evidence, ownership changes, nested or omnibus activity where relevant, Travel Rule data handling, unusual counterparties and changes in geographic exposure. The control should identify when additional review is needed without assuming every offshore or unhosted-wallet exposure is prohibited.

If blockchain analytics are used, test the vendor result alongside the underlying address and transaction evidence. A change in vendor attribution should not erase the original case evidence. Versioning should allow an investigator to reproduce what the system knew at the time.

Case-management acceptance criteria

The case should contain the alert reason, contributing features, source systems and timestamps. It should show customer profile, relevant device and authentication history, beneficiary information, payment details, previous alerts, fraud intelligence and any external evidence used. Investigators should be able to distinguish a fact from a model inference.

Disposition fields should be specific enough to support feedback. False positive is usually too broad. A case might close because the device change was a verified upgrade, the beneficiary was a long-standing supplier under another customer account, the payment matched a documented property transaction or the VASP was an established counterparty consistent with customer history. Those explanations are valuable for tuning.

If a case becomes a fraud report, recovery action, SAR/STR assessment or sanctions escalation, the downstream reference should be linked without assuming the same workflow or confidentiality rules apply to all functions.

Positive, negative and boundary testing

Positive testing proves that known attack patterns are detected. Negative testing proves that normal activity remains usable. Boundary testing is where many important defects appear: a payment one unit below a threshold, a beneficiary risk signal arriving one second after the decision, a customer changing device and phone number on the same day, or a card transaction authenticated successfully but followed by unusual merchant activity.

Evasion testing should vary the obvious indicators: slow down velocity, split amounts, rotate devices, use established beneficiaries and switch channels. The purpose is not to create a perfect detector. It is to understand which signals remain effective when criminals change superficial behaviour.

Fairness and customer-impact tests should include vulnerable customers, accessibility tools, travel, language variation and customers with legitimately unusual financial patterns. A control can be statistically accurate and still create unacceptable harm for a segment that was poorly represented in design data.

Operational readiness

Before production, teams need playbooks for customer contact, payment recovery, receiving-bank outreach, high-risk beneficiary review, service outage, model rollback and escalation to AML or sanctions specialists. Roles should be clear outside office hours if the payment rail operates continuously.

Management information should monitor prevented and actual loss, confirmed fraud conversion, false positives, customer abandonment, latency, service availability, recall or recovery outcomes, complaints and beneficiary-risk precision. Metrics should be segmented by rail and customer type so improvement in one channel does not hide deterioration in another.

The final readiness question is whether a reviewer six months later can reconstruct the decision from evidence. If the answer depends on a model version that no longer exists, an external service response that was not stored or a policy interpretation no one can trace, the control is not audit-ready even if it performed well statistically.

Masterclass: when genuine authentication meets a dangerous payment

This is a composite educational case built from common scam and mule-account patterns described in public industry and regulatory material. It is not an account of a specific enforcement action, bank or customer. The purpose is to show how a genuine customer, a valid authentication event and a technically correct payment can still create serious fraud and financial-crime risk when the beneficiary is unsafe.

The customer journey

A customer is preparing to pay a deposit connected to a property purchase. The customer has used the same mobile device for months and logs in normally. The device is bound, the biometric check succeeds and there is no obvious sign of account takeover. Earlier that day the customer receives a convincing message that appears to come from a professional involved in the transaction. The message gives new bank details and creates urgency around a supposed deadline.

The customer creates a new beneficiary and initiates a large payment. The amount is unusual compared with ordinary monthly spending but plausible for the stated purpose and within the customer's available funds. A simple authentication model would see a genuine device, genuine biometric approval and an amount the customer can afford. None of those facts proves that the beneficiary is safe.

Where a payee-verification service is available, assume the account name matches the name provided by the fraudster. The match removes one possible sign of misdirection but still does not establish that the account is legitimate. The fraudster may control an account opened in the matching name or may have tailored the social-engineering story to the real account holder.

The beneficiary side changes the picture

The receiving account has little history. Within the previous week it has received several unrelated inbound payments followed by rapid onward transfers. One earlier payment has already been reported as fraudulent by another institution, and that intelligence has reached the sending bank's beneficiary-risk service. The account is therefore not merely new; it has contextual evidence associated with scam proceeds.

The payment engine now has two different stories. Customer-authentication evidence is reassuring. Beneficiary-risk evidence is not. A mature decision engine preserves both rather than allowing the stronger authentication score to cancel the payee risk.

The bank applies the intervention allowed by its local framework and policy. This might be a targeted warning, additional customer confirmation, a temporary referral, a call or another form of proportionate friction. The exact action depends on jurisdiction, scheme rules, contractual terms and transaction risk. The case should not be read as a universal instruction to delay or block all high-risk-looking instant payments.

During the intervention the customer reveals that an external person is directing the payment and has instructed them not to contact the normal professional relationship because it would supposedly jeopardise completion. That new evidence materially increases scam risk. The payment is not executed under the bank's applicable procedures.

Composite APP scam timeline showing a genuine session, manipulated customer, beneficiary-risk evidence, intervention and downstream financial-crime handoffs.

What each control actually contributed

Authentication answered a narrow question: was the session being operated through the customer's legitimate authentication method? It did not answer whether the customer was being deceived. Payee verification answered another narrow question: did the submitted name and account identifier correspond under that service's rules? It did not prove the account was trustworthy.

Beneficiary intelligence supplied the most important additional context because it connected the receiving account with prior fraud outcomes. Customer dialogue then converted a statistical concern into stronger factual evidence about the scam narrative. No single control solved the case. The outcome came from combining identity, payment, beneficiary and human evidence.

This is an important design lesson. Banks often invest heavily in customer-side authentication because it is visible and measurable. Scam prevention also needs payee-side intelligence, payment context and a process for handling a genuine customer's insistence on making a dangerous payment.

If the payment had already settled

Change the timing. Suppose the beneficiary-risk signal arrives after settlement. The prevention opportunity has passed, but the control problem has not ended. Payment operations can use whatever recall, return or beneficiary-bank engagement the relevant rail permits. The receiving institution may be able to restrict remaining funds where law and policy allow. Fraud operations can support the customer and reimbursement process. Investigators can identify linked accounts and transactions. AML teams can assess whether the facts meet the applicable suspicious-activity reporting threshold.

The receiving account also becomes intelligence for future payments. Its risk status may change from unconfirmed concern to a stronger classification if evidence supports that conclusion. The bank should preserve effective dates so it can show that the later intelligence did not exist when the first payment was processed.

That temporal distinction is crucial for audit and model review. A decision can be reasonable based on the information available at 10:00 and look obviously wrong when reviewed at 16:00 after several fraud reports arrive. Good systems let reviewers reconstruct both states.

Reimbursement is not globally uniform

If this case occurred in the United Kingdom and fell within the Payment Systems Regulator's APP scam reimbursement rules, the bank would assess reimbursement under that framework, including its scope, exceptions, timing and applicable cap. That framework took effect on 7 October 2024 for in-scope Faster Payments and CHAPS payments and has since been consolidated in PSR policy material.

A bank outside that scope may face a different statutory, scheme, contractual or voluntary reimbursement model. The learning point is therefore not that every victim receives the same outcome. It is that the case platform should capture enough evidence for the correct local liability and reimbursement decision: payment type, customer actions, warnings, vulnerability considerations where relevant, beneficiary intelligence, timing and recovery activity.

Fraud-to-AML handoff

Stopping a scam payment does not automatically create a suspicious activity report. Fraud and AML teams need a defined handoff that reflects local law. The sending customer's behaviour may be fully explained as victim activity. The receiving account may create a separate suspicion if the institution has relevant information and jurisdictional responsibility. A network of repeated victim payments followed by rapid dispersal can be more significant than any single attempted payment.

The handoff should therefore transfer facts rather than labels. Useful facts include customer statement, beneficiary account, transaction references, receiving institution, fraud report identifiers, device or session information, linked payments, recovery actions and the reason the beneficiary was considered risky. AML can then make its own decision under the applicable reporting threshold.

BA and architecture lessons from the case

The case exposes several requirements that can be missed in a feature-by-feature design. Beneficiary intelligence must arrive quickly enough to influence a payment when the rail allows it. Authentication results and beneficiary risk must remain separately visible. Payee-verification outcomes need their own field and should not be collapsed into an overall safe payee indicator. Customer warnings and acknowledgement need timestamps and versioned message content. A later fraud report must update future risk without rewriting the state that existed at the original decision time.

The architecture also needs an end-to-end identifier strategy. Customer ID, account ID, beneficiary ID, payment ID, device ID, fraud case ID, recall reference and AML case ID should be linkable through controlled interfaces. Without that lineage, the organisation cannot reliably join customer deception with the later movement of proceeds.

Testing the scenario properly

A single happy-path test is inadequate. Test a genuine customer and safe new beneficiary to prove the bank does not over-friction normal behaviour. Test a genuine customer and risky beneficiary with a payee match. Test a mismatch that is innocent because of a trading name. Test a beneficiary-risk signal arriving after settlement. Test the service being unavailable. Test a customer who ignores the warning where the local framework allows the payment to proceed.

The expected result should cover both customer experience and evidence. The tester should verify the warning shown, decision reason, latency, case creation, data lineage and downstream handoff. That is what turns the scenario from a fraud-rule demonstration into a bank-grade control test.

The core lesson

The strongest conclusion from the case is not that authentication failed. Authentication did the job it was designed to do. The weakness was the gap between proving who initiated a payment and understanding whether the destination and purpose were safe. Digital financial-crime architecture becomes more effective when those questions are kept distinct and the evidence is brought together at the right decision point.

Knowledge check and glossary

Use these questions to test whether the control logic is understood, not merely memorised.

Why can valid authentication coexist with a scam? Because authentication establishes confidence that the authorised customer or enrolled authenticator is involved. It does not establish that the customer's payment purpose is genuine or that the beneficiary is trustworthy. Social engineering exploits that boundary by persuading a real customer to authorise the criminal's desired payment.

Why is a new device only a signal? Customers replace phones, reinstall apps, travel and use accessibility tools. A device change becomes more meaningful when combined with other evidence such as credential reset, new beneficiary, unusual transaction, remote-access indicators or behaviour that differs materially from the customer's history.

What makes velocity useful? Velocity reveals compression: many actions, beneficiaries or value movements in a period that is unusual for the relevant customer or peer group. It must be segmented and contextualised because high-volume businesses and some legitimate customers naturally transact quickly.

Does Verification of Payee prove a beneficiary is legitimate? No. It checks the relationship between the submitted name and account identifier under the applicable service rules. A criminal-controlled account can still produce a match. A mismatch can also be innocent because of business names, joint accounts, abbreviations or data differences.

Why are instant payments operationally demanding? Controls that need to influence execution have to respond within the rail's timing requirements. That increases the importance of low-latency data and defined fallback. Post-event recovery, investigation and intelligence feedback still remain valuable after settlement.

Must every instant payment undergo identical sanctions screening? No. Sanctions obligations depend on jurisdiction, legal entity, customer, currency, rail and applicable sanctions regime. For example, the EU Instant Payments Regulation includes a specific periodic verification obligation for PSPs offering instant credit transfers in relation to targeted financial restrictive measures. Other frameworks can require different controls.

What is beneficiary intelligence? Information about receiving accounts and counterparties derived from confirmed fraud outcomes, payment history, recalls or returns, network links, external intelligence and other lawful sources. It should carry provenance, confidence, effective date and governance so weak or stale information does not become a permanent adverse label.

Why can card testing be missed by transaction-by-transaction rules? Individual low-value authorisations can look normal. The criminal pattern appears in the sequence: repeated probes, merchant diversity, declines, rapid retries and later movement to higher-value exploitation. Sequence detection therefore adds information that a single transaction does not contain.

What is the main difference between issuer and acquirer fraud visibility? The issuer knows the cardholder relationship and spending history. The acquirer knows the merchant relationship, processing profile and settlement behaviour. Both can see part of the same event but face different control questions.

How should blockchain analytics be treated? As analytic evidence that needs provenance and corroboration, not as an unquestionable verdict. Investigators should retain addresses, transaction hashes, attribution source and confidence where available and combine them with customer, VASP and transaction evidence.

Does a first payment to a VASP automatically require enhanced due diligence? Not universally. It can be one factor in a risk-based assessment. The appropriate response depends on customer profile, amount, VASP risk, scam indicators, source-of-funds concerns, jurisdiction and the institution's approved framework.

What should happen when a real-time dependency fails? The response should follow a pre-agreed fallback mapped to the applicable legal and scheme obligations. Possible actions differ by rail and jurisdiction. A universal fail open or fail closed rule is usually unsafe.

Why keep historical risk states? Because later intelligence can make an earlier transaction look obviously suspicious. Audit needs to distinguish what the bank knew at decision time from what became known afterwards. Effective-dated data protects that distinction.

When should a digital fraud alert become an AML case? When the facts and local framework justify an AML assessment, not automatically because fraud is present. A victim customer's unusual payment may be explainable, while a receiving account repeatedly collecting and dispersing scam proceeds may create a different suspicion question.

What makes a strong acceptance test? It proves the decision, evidence, timing and customer outcome. It should cover true attacks, legitimate lookalikes, boundary cases and service failures, and verify that downstream cases retain the correct reason codes, timestamps and source data.

Glossary for delivery teams

Account takeover: unauthorised control of a customer's account or digital session, often involving compromised credentials, device control or social engineering.

Authorised push payment scam: a scam in which the payer is deceived into authorising a transfer to an account controlled by or benefiting the criminal. The exact legal terminology and reimbursement treatment vary by jurisdiction.

Beneficiary intelligence: risk information about a receiving account or payee assembled from payment outcomes, fraud reports, network relationships and other lawful sources.

Behavioural signal: evidence derived from how a customer or device interacts with a service, such as navigation, timing or typing characteristics. It is probabilistic rather than conclusive identity proof.

Card testing: low-value or repeated authorisation attempts used to determine whether stolen card credentials can be exploited.

Confidence: an indication of how strongly evidence supports an attribution or risk classification. Confidence should not be confused with legal certainty.

Cross-channel correlation: linking activity across cards, account transfers, digital sessions, cash, merchant activity or virtual-asset touchpoints to reveal a broader pattern.

Device binding: association of an enrolled device with a customer or authenticator so subsequent sessions can be compared with the known device relationship.

Effective date: the date and time from which a risk attribute or piece of intelligence was valid. It is essential for reconstructing historical decisions.

Fallback: pre-defined behaviour used when a required or risk-control dependency is unavailable or too slow. Fallback should be mapped to the specific rail and jurisdiction.

Mule account: an account used to receive, hold or move criminal proceeds, whether the account holder is knowing, complicit, coerced or deceived. Operational classification should reflect the evidence available.

Payee verification: a service that compares beneficiary name and account information before a payment. Product names and response models differ by market.

Pre-execution control: a check capable of influencing whether or how a transaction proceeds before settlement or authorisation is final under the relevant rail.

Recovery: post-event action intended to retrieve or preserve funds, including recall, return, receiving-bank engagement or other lawful measures available under the payment framework.

Risk-based approach: allocation of control intensity according to identified and assessed risk rather than applying the same treatment to every customer or transaction.

Strong customer authentication: authentication using factors and rules defined by the applicable regulatory framework. In the EEA it has a specific PSD2 meaning; the phrase should not be assumed to carry identical legal effect globally.

Token provisioning: creation or activation of a payment token, for example when a card is added to a digital wallet. Provisioning can be an important fraud-control point.

Travel Rule: FATF-derived requirements concerning originator and beneficiary information for qualifying virtual-asset transfers as implemented by jurisdictions. Local thresholds and implementation details vary.

VASP: virtual asset service provider, using FATF terminology. Whether a particular business falls within the definition depends on its activities and the relevant implementation framework.

Verification of Payee: the EU term used in Regulation (EU) 2024/886 for checking the intended payee against the payment account identifier. Other markets use different names and rules.

Velocity: frequency, value or concentration of events within a defined period, interpreted against customer, product and peer context.

References and further reading

The sources below are public materials used to anchor the chapter. They cover different jurisdictions and should be applied within their stated scope rather than treated as one universal rulebook.

Global AML/CFT and virtual-asset standards

European payments and authentication context

UK APP scam reimbursement context

Authentication and US supervisory reference material

These references are deliberately weighted toward standards bodies, regulators and public authorities. Card-scheme operating rules and proprietary fraud-intelligence sources can be important in implementation, but their contractual or commercial content should be consulted directly by institutions entitled to use them rather than reproduced as public course material.