Cards, Prepaid, E-Money and Wallet Financial Crime Controls

Cards, prepaid products, electronic money and wallets are not one legal or risk category. A card may access a bank account, credit line or prepaid balance. A wallet may store e-money, tokenise payment credentials or provide another service. The name wallet does not establish that it holds customer funds or uses virtual assets.

Product risk depends on funding sources, reloadability, balance and transaction limits, transfers, cash withdrawal, international use, redemption and who can access the instrument. A closed-loop gift product differs from a reloadable transferable wallet. National law defines the perimeter and any exemptions; do not publish one universal anonymous-product limit.

CDD, sanctions, fraud prevention and safeguarding serve different purposes. Tokenisation protects payment credentials; strong authentication helps verify control of a session; safeguarding protects customer funds under applicable rules. None alone proves customer identity, beneficial ownership or legitimacy of activity for AML purposes.

FATF risk-based guidance for prepaid cards, mobile and internet payment services provides useful principles, while Recommendations 10, 15 and 16 are relevant standards. Binding obligations and thresholds must be mapped to the actual jurisdiction and service.

Identify the financial product behind the interface

Start by identifying what the customer actually holds and can do. A debit card can access a bank deposit. A credit card can access a credit facility. A prepaid instrument can provide access to previously funded value. A wallet can hold a monetary balance, display several payment credentials or provide another service. These arrangements differ in legal perimeter, funding, customer relationship and value movement. The marketing name should be recorded as context, while the assessment follows the actual product and applicable national framework.

Identify the entities involved. An issuer provides the relevant instrument or account service. A processor can supply technical authorisation or ledger functions. A programme manager can operate customer-facing or distribution tasks under an arrangement. An agent or distributor can sell or load products. A bank can provide settlement or safeguarding accounts without being the direct provider to every end user. One group can perform several functions through different entities. Map those roles before allocating obligations.

The legal and economic claims matter. Is the balance a bank deposit, e-money under the relevant law, a contractual prepaid entitlement or another form of value? Who owes the customer repayment or redemption? Where is value held, and who controls transfers? Do not assume deposit protection, safeguarding or redemption rights merely because the interface resembles a bank account. Those questions require the applicable legal model and terms, and they influence both customer treatment and control design.

Build a feature-based risk assessment

Features determine what the product can do. Assess funding methods, reloadability, balance capacity, transaction limits, transfer capability, cash withdrawal, international use, redemption, refunds and access by other people. A product confined to a particular merchant network creates different opportunities from one that can transfer value to anyone and withdraw cash. A nominally low limit can still permit substantial movement through repeated loading or several instruments where the model allows it.

Record the exact scope of limits. A balance limit controls stored value at a point in time; a funding limit controls incoming value over a defined period; a transaction limit controls one event; an aggregate customer limit controls a linked population. Those are different constraints. Identify currencies, channels, reset periods and relevant customer links. A field called maximum amount is not enough for an analyst or tester to understand the product's exposure.

National law can provide particular exemptions or simplified arrangements with conditions. Establish the applicable current framework, eligibility, features, thresholds and consequences if conditions cease to be met. Do not publish one universal anonymous-card limit or infer an exemption from a product's commercial label. Bank risk limits may be stricter or address different concerns. Store legal conditions and policy choices separately so the institution can explain why a transaction or customer was restricted.

Understand who funds and who uses the product

The account holder, funding-source owner, cardholder, authorised user and beneficiary can be different people. A parent can legitimately fund a child's supported product; an employer can distribute permitted staff funds; a business can issue instruments to authorised employees. Other arrangements can conceal control or enable misuse. The bank should identify the roles relevant to the product and assess third-party funding according to applicable requirements, evidence and risk.

Funding ownership is a proposition to test, not an assumption created by a successful load. An authenticated funding transaction can still involve compromised credentials or an unrelated payer. Conversely, a name difference can reflect a legitimate relationship or abbreviated records. Use reliable evidence and context proportionately. Where the bank has limited visibility of the funding instrument's owner, document that limitation and the approved controls rather than claim verification the service cannot perform.

Users also change. A device can be replaced, a supplementary card added or an authorised employee removed. Product access should reflect current authority and permitted use. Strong authentication helps protect access, but it does not establish beneficial ownership or the economic purpose of every transfer. Customer understanding and access-security evidence should be connected where relevant while retaining their different meanings.

Follow the lifecycle of value

The lifecycle can include funding authorisation, funding settlement, balance credit, purchase authorisation, clearing, ledger posting, peer transfer, cash withdrawal, refund and redemption. A record of one event does not establish all the others. A declined authorisation does not show completed spending. An expired authorisation hold differs from a refund after a settled purchase. A pending funding event should not be treated as received money unless the approved product and accounting model supports that state.

For a fictional example, a wallet records a load request, permits some spending under its approved model and later discovers the funding failed. The bank needs to understand whether it extended credit, incurred an operational loss or created another exposure. The ledger should reflect actual value and obligations. An AML analyst should not report the original load as settled funding simply because the customer interface briefly showed an available balance.

Net balances can conceal large flows. A customer can repeatedly load and spend value while maintaining a low end-of-day balance. Monitoring should use the activity relevant to its purpose, including gross flows, timing, counterparties and funding where appropriate. A small current balance does not prove low cumulative exposure. Likewise, many small legitimate purchases should not become suspicious merely because their count is high; product and customer context matter.

Distinguish security, fraud, AML and safeguarding

Tokenisation can replace sensitive payment credentials with another representation used within a defined system. It can reduce exposure of original credentials, but it does not identify the economic owner of funds or establish legitimate activity. Strong authentication can help show control of a session or device. It can coexist with a customer who is willingly moving criminal proceeds, or with an authorised user acting outside the intended commercial purpose. Security controls and AML controls answer different questions.

Fraud controls can identify account takeover, stolen funding credentials, unauthorised transactions and synthetic identities. AML controls can assess suspicious use, concealed relationships and patterns inconsistent with customer understanding. Safeguarding, where applicable, concerns the protection or treatment of customer funds under its own framework. A correctly safeguarded balance can still be used suspiciously; a clean name screen can coexist with fraud. Governance should preserve these boundaries while sharing relevant facts lawfully.

Chargebacks and disputes also have defined scope. They can resolve a transaction dispute under scheme and service rules, but they do not automatically recover all funds or settle every AML question. A partial recovery should not be recorded as complete. A dispute outcome can provide useful evidence, but an investigator should assess what it establishes. Distinct case and financial states prevent one administrative result from obscuring unresolved exposure.

Recognise cash-out and transfer patterns fairly

A wallet funded from several sources and transferring quickly to another wallet can justify review, especially where the counterparties or purpose are unclear. Cash withdrawal can reduce visibility of later value movement. These are features and hypotheses, not universal proof of laundering. Legitimate customers can use third-party support, business transfers or cash access under supported arrangements. The analyst should establish relationships, source quality, purpose and timing.

Linked-product analysis can help identify aggregate use where lawful and appropriate. Reliable customer identifiers can connect instruments held by one customer. Device or address links can support inquiry but may also reflect households, workplaces or shared access. Preserve confidence and uncertainty in those links. Avoid concluding that all products on one device belong to one person without evidence.

An alert should provide the lifecycle rather than isolated suspicious-sounding events. Show funding, transfers, withdrawals, refunds and actual statuses alongside customer context. Identify which information is unavailable. Investigators can then test alternatives and decide the appropriate outcome under the actual reporting, fraud, sanctions and service frameworks. A high score without supporting facts is a weak basis for a consequential customer decision.

Maintain boundaries when the product changes

New features can change the assessed risk. Adding reloadability, peer transfers, cash withdrawal, international acceptance or another funding method can invalidate assumptions behind the original approval. A limited product's eligibility for a particular legal treatment may depend on features and conditions. Reassess the actual current model before release and identify affected existing customers or balances.

Feature restrictions need execution evidence. A product described as non-transferable should not permit value movement through an unintended refund or alternative endpoint. A cash-out restriction should reach every relevant channel in scope. A limit should use the correct currency and aggregate population. Test legitimate permitted activity as well, so controls do not unnecessarily block supported use. The bank should know what the product can do in practice, not only what its terms say.

Practitioner decision standard

A sound product assessment identifies legal entities, customer claims, actual features, funding and delivery channels, applicable duties, evidence and control points. It explains limits, exemptions or simplified arrangements with their jurisdiction and conditions, and distinguishes them from bank policy. It follows value through technical and financial states, preserves customer and instrument relationships, and maintains those facts through change, incidents and closure. That is the basis for effective cards and wallet controls across different delivery models.

Follow value from funding to redemption

Identify who opens the product, owns the funds, loads value, uses the instrument and receives transfers or withdrawals. Third-party funding may be legitimate but needs a coherent explanation and applicable controls. Multiple products sharing a device or funding source can support investigation without proving they belong to the same person.

Monitor the lifecycle rather than isolated card authorisations. Loading, spending, peer transfers, refunds, withdrawals and redemption can move value through different rails. A low-value transaction limit may not control aggregate exposure if customers hold many products or rapidly reload them.

Separate authorisation, clearing, settlement and ledger posting. A declined authorisation differs from a settled purchase; a refund differs from a reversal of an authorisation hold. Preserve these distinctions in monitoring and investigations so a customer is not treated as having received value that never settled.

Consider account takeover, stolen credentials, synthetic identities, mule activity and unexplained cash-out. Fraud teams may protect the customer while AML teams assess suspicious movement of funds. A chargeback resolves a scheme dispute under its rules; it does not automatically resolve AML concerns or prove that all money was recovered.

Represent parties and instruments separately

The data model should distinguish customer, authorised user, instrument, wallet, funding source, counterparty and provider role. A customer can hold several instruments. One wallet can represent several credentials without storing a monetary balance. One prepaid account can support a primary and supplementary card. A corporate customer can permit several employees to use instruments. Relationships should have their own meaning and effective dates rather than be inferred from one account number.

Preserve source and confidence for relationship facts. A bank-verified customer link differs from a device similarity or customer assertion. A funding source can be known to belong to the customer, known to belong to another person or not fully identified under the service's available information. Those states should be visible to analysts. Mapping every unknown funding source to the wallet owner creates an unsupported ownership conclusion.

Token mappings need appropriate safeguards and analytical continuity. Where tokens change or several tokens refer to one underlying instrument, the relevant control should understand the relationship to the extent lawfully available and necessary. Protect sensitive credentials and avoid exposing them unnecessarily. The objective is useful provenance and correlation, not storing raw payment credentials in every investigation record.

Maintain a financial event taxonomy

Define funding request, authorisation, hold, clearing, settlement, ledger credit, spend, peer transfer, withdrawal, reversal, refund and redemption according to the actual model. Some services combine steps, while others have delays and separate rails. The taxonomy should preserve the economic distinction. A hold release reduces a temporary reservation; a refund after settlement is a movement of value. A failed load should not be recorded as settled money merely because the request was accepted technically.

Events should retain original references, amount, currency, relevant parties, event time, receipt time and status. Link subsequent corrections and reversals to the original without deleting it. An analyst should be able to reconstruct both the intended transaction and actual execution. The latest balance alone cannot show whether a suspicious pattern occurred before a refund, whether a cash withdrawal succeeded or whether a retry duplicated value.

Monitoring populations should be reconciled against execution and ledger populations. Different controls may use authorisations, settled transactions or another defined set. Specify that choice and its purpose. Do not combine events indiscriminately and count one purchase several times. Conversely, do not exclude a relevant movement because it arrived through a refund or redemption feed rather than the ordinary purchase stream.

Make limits precise and explainable

Limits need a subject, measure, period, currency, scope and basis. A customer-level monthly funding limit differs from an instrument-level single-transaction limit. A balance limit differs from a cumulative flow limit. A policy limit differs from a statutory condition for particular treatment. The system should explain which constraint applied and why. A generic decline reason such as amount exceeded can conceal the actual rule and hinder customer support.

Aggregation requires reliable links and defined concurrency behaviour. If a customer has several cards, determine which activities count toward a customer-level limit and how concurrent requests are handled. Test repeated loads across channels and currencies. Apply conversion methods and timing according to approved requirements. An apparently strong limit can fail if each channel keeps its own unreconciled counter or pending activity is treated inconsistently.

Changes need historical traceability. Preserve the limit and product features applicable when a transaction occurred. A customer moving into another supported product tier may receive different capabilities, but the transition should have the required evidence and approval. A manual override should record authority, scope, duration and rationale. An override cannot create permission to breach a mandatory legal restriction.

Assess loading and redemption as control points

Loading introduces value and can connect a product to external funding sources. Understand supported methods, third-party funding rules, confirmation and failure states. If the product credits value before funding finality, identify the resulting financial exposure and approved controls. A rapid sequence of loads and withdrawals may be relevant, but the analyst needs actual settled funding and withdrawal results rather than a mixture of requests and failed events.

Redemption can change the recipient or channel of value. Identify the customer entitlement, permitted destination, authority, fees and execution under the applicable model. A redemption to a new account should preserve the instruction and relevant verification. Closure of a wallet should not erase the record of who received the residual balance. If another person requests redemption, assess the authority and service conditions rather than infer permission from possession of a device.

Refunds can also introduce or redirect value. Link them to the original purchase and actual destination where available. A merchant refund may be legitimate, erroneous or abusive. A high refund ratio or changed destination is a hypothesis requiring context. Preserve enough of the original sale, refund reason and execution to investigate without assuming every negative purchase amount reduces risk.

Join fraud and AML facts without merging decisions

Fraud indicators can explain why a customer account behaves unusually. Stolen funding credentials, account takeover or synthetic identity can produce activity that the named customer did not authorise. Fraud teams may take protective action, while AML teams assess movement of proceeds and reporting requirements. The customer may be a victim, participant or person whose role is not yet known. Preserve that uncertainty until evidence supports a conclusion.

Shared facts should have controlled access and purpose. Device events, authentication results, transaction history and customer communications can be relevant to several teams. Protected reporting decisions and sensitive security details may require narrower access. Operational instructions should give execution teams the action needed without unnecessary disclosure. A shared incident identifier can connect work while maintaining separate decision records.

Closure should specify what was resolved. A chargeback can recover a particular amount while a wallet network remains under investigation. A password reset can secure access while earlier transfers remain unexplained. A suspicious report can be submitted while customer remediation is still pending. Systems should not allow one resolved ticket to erase the other financial or legal positions.

Preserve proportionality in network and device analysis

Device, address and funding-source links can reveal patterns not visible in individual accounts. They can also reflect families, shared workplaces, assisted access or ordinary business arrangements. Label the link type and reliability. Use stronger evidence where identity matters and retain a review path for uncertain relationships. A network diagram should not visually imply common ownership merely because several customers share a technical attribute.

Validation should include both known abuse patterns and legitimate shared use. Test families using one supported device, corporate employees using business funding, repeated legitimate purchases and customers who change phones. Test compromised credentials, unsupported third-party loads, coordinated cash-out and identity inconsistencies. Assess whether the system detects relevant patterns without creating unsupported conclusions about ordinary users.

The outcome should reflect the facts and applicable requirements. A device-risk signal can justify step-up or review under policy. It does not by itself establish a legal identity, a sanctions target or suspicious ownership. Analysts should explain why the signal matters to the particular transaction or customer and what additional evidence supports the decision.

Control outages and delayed events

An outage can affect authorisation, ledger posting, screening, monitoring or customer display differently. Identify which function failed and what activity remained possible. A product may keep accepting transactions while analytical events are delayed. Another may decline safely but show inaccurate available balance. The incident plan should define approved contingency behaviour, evidence preservation and escalation according to the actual service and obligations.

Recovery should reconcile late and duplicate events, financial positions and control populations. Preserve event time so a delayed batch does not falsely appear to be simultaneous customer activity. Prevent retries from executing value twice. If a restriction arrived during the outage, establish which paths received it and whether any activity occurred outside the intended control. Repair should address both financial correctness and historical control exposure.

Offline features require explicit assessment. If the instrument or channel supports activity without immediate central connectivity, determine the actual limits, legal conditions, risk and available controls. Do not assume a central status change instantly prevents every offline event. Testing should reflect the product's real capability and reconcile subsequent events when connectivity returns.

Keep the product inventory current

The inventory should record legal model, entities, customer population, features, limits, channels, currencies and controls. A feature change can affect several domains: CDD conditions, monitoring, fraud exposure, safeguarding where applicable and customer communication. Approval should identify those impacts and test them before release. A technical flag enabling transfers can materially change the financial product even if the marketing name stays the same.

Older FATF prepaid and mobile-payment guidance should be used within its historical context. The current publication page warns that later standards, including 2025 risk-based revisions, are not reflected in that document. Current national law and updated standards should guide the applicable assessment. This prevents a useful conceptual source from becoming an outdated universal rulebook.

End-to-end assurance question

Select one customer and reconstruct the products they held, supported funding, actual value events, relevant counterparties, applied limits and decisions. Select one incident and identify the financial state, security response, AML assessment and customer outcome. Select one feature change and show the approved new capabilities and tested controls. These exercises demonstrate whether the bank understands the product's actual ability to store and move value throughout its lifecycle.

Feature and limit assurance

Test a non-reloadable product, reloadable wallet, third-party load, peer transfer, cash withdrawal and a refund to a changed destination. Expected controls should follow features and local law rather than the product's marketing name.

Test aggregate activity across linked instruments where lawful and appropriate. Verify that limits apply to the intended population and cannot be bypassed by channel or currency changes. An internal risk limit and a statutory exemption threshold should be stored and explained separately.

Review missing-data, offline, duplicate and delayed-event handling. Balanced ledger totals do not establish that every transfer carried required customer or counterparty information.

Case method: establish the product and actual financial events

The following cases are fictional. Amounts, periods, limits and decisions are illustrative rather than regulatory thresholds. Establish the product's legal model, provider roles, jurisdiction, features and applicable requirements before deciding a live case. Reconstruct funding, transfers, spending and cash-out using actual event states. Security success, a low balance or a balanced ledger does not establish the legitimacy of the complete value chain.

Case 1: third-party loads followed by cash-out

A reloadable wallet receives repeated loads from several cards. Soon afterward, it transfers value to another wallet that withdraws cash. The device graph links several other customers to the receiving wallet. The sender says relatives are funding shared household expenses. Fraud controls report no confirmed stolen-card event, and the product remains within its individual transaction limits.

The analyst should establish settled funding, actual transfers and successful withdrawals, separating failed requests and reversals. Identify available funding-owner evidence and relevant customer relationships. Determine whether the claimed household arrangement fits the payer and recipient pattern, timing and history. Device links can guide inquiry but should remain labelled by their reliability. Shared devices do not automatically establish that one person owns every wallet.

A coherent explanation supported by reliable evidence can weaken the initial concern. Contradictory customer statements, unrelated funding owners or deliberately obscured recipients can strengthen it. The investigator should record which facts distinguish those alternatives. Compliance with individual transaction limits is relevant to the product rule but does not settle the suspicious-activity question. Likewise, absence of confirmed credential theft does not prove legitimate purpose.

Any action should use the correct basis. Fraud protection, additional information, a policy restriction, sanctions disposition and suspicious reporting have different tests. Scope the control to the established exposure and lawful authority. The lesson is to investigate the joined funding-transfer-cash-out chain, while preserving uncertainty about identity links and avoiding a verdict based only on a technical score.

Case 2: a closed-loop product gains transfer capability

A prepaid product was approved for spending within a defined merchant network. A software release adds a function that sends unused value to another customer's balance. The product team describes it as a convenience feature and believes the original low-risk assessment still applies because the balance cap is unchanged. The legal treatment and policy assumptions depended partly on the original features.

The review should identify exactly what value movement is now possible. Can recipients spend elsewhere, redeem value or transfer again? Which entities execute the function? What national conditions or obligations apply to the changed product? The original approval cannot be extended solely because the product name and balance limit remain the same. A new transfer function may change the relevant risk and perimeter without increasing the stored amount.

Determine whether the feature was assessed and approved before activation. Identify existing customers and transactions affected, and what lawful limits or suspension are needed while review occurs. Do not assume the feature is unlawful in every jurisdiction; apply the actual framework and competent interpretation. If the service can continue with revised evidence and controls, document that basis and conditions.

Acceptance testing should compare the approved product description with every relevant channel and endpoint. Test whether alternative refunds or adjustments also create transferability. The lesson is that product risk follows capabilities and conditions, so a feature change can invalidate a legal or policy assumption even when headline limits are unchanged.

Case 3: many instruments bypass an intended customer limit

A bank's policy limits cumulative funding for a particular product tier at customer level. Each card enforces a separate local counter. A customer obtains several instruments and uses different channels to load them. Every individual request passes, while the combined activity exceeds the intended policy boundary. Some records are in different currencies, and pending loads are counted inconsistently.

First identify the approved rule: subject, period, currencies, channels, included events and pending-activity treatment. Determine whether it is a policy control or a legal condition. Reconstruct the reliable customer-instrument relationships and actual funding states. Do not aggregate unrelated customers because they share an address or device. The defect may be a scope mismatch between the intended rule and implementation rather than deliberate customer evasion.

Assess the affected population and consequences. If a statutory condition was involved, obtain the appropriate legal assessment and action. If a policy boundary was involved, decide the response under that policy and evidence. Investigate deliberate concealment only where facts support it. Customers should not be accused of bypassing a rule that the interface invited them to use without clear restrictions.

Repair should align the counters and concurrency model with the approved subject and scope. Test multiple channels, currencies, simultaneous requests, reversals and customer-tier changes. Preserve the rule version applicable to historic decisions. The lesson is that a limit is meaningful only when its population and event semantics are defined and executed consistently.

Case 4: a failed load is treated as received money

A wallet credits an available balance after a funding request. The funding later fails, but the analytical feed records the original request as a settled load. The customer spends some value before the failure is resolved. Operations opens a loss investigation, while AML monitoring describes the customer as receiving and moving funds from the external source.

Reconstruct the funding and spending states. Identify the approved crediting model, actual settlement result, ledger entries and customer instructions. Determine whether the product extended provisional availability or whether the credit was an error. The financial exposure and customer obligation follow the actual arrangement and applicable rules. The investigator should not claim the external funds were received when they were not.

The anomaly can still matter. Repeated exploitation of failed funding, misleading instructions or linked activity may support a fraud or AML hypothesis. An isolated operational defect may have another explanation. Test the pattern and customer evidence rather than infer intent from the balance error. Preserve the original events and correction so later review can understand both the system failure and customer behaviour.

Recovery should correct financial and analytical records without erasing history or creating duplicate debits. Reconcile the affected population and assess whether earlier alerts or decisions relied on false states. The lesson is that transaction status accuracy is necessary for sound financial-crime reasoning; technical acceptance and actual receipt of value are different facts.

Case 5: account takeover and suspicious onward transfer

A customer's device and credentials are compromised. The attacker changes a beneficiary and transfers the wallet balance to another account. Fraud teams secure access and reimburse the victim according to the applicable decision. The recipient then moves value onward. A shared incident record marks the fraud case resolved, causing the AML referral to disappear from the queue.

The bank should distinguish the victim's position, unauthorised transfer, recipient activity and reporting assessment. Securing access and addressing customer loss are material outcomes, but they do not resolve the onward movement of proceeds. The recipient's role may be knowing participation, account compromise or another circumstance requiring evidence. Preserve uncertainty and assess the actual facts under the relevant framework.

Operational action should reflect each domain. Fraud owners manage access protection and remediation. Investigators assess recipients and onward transactions. Sanctions specialists apply any relevant legal measure. Reporting decisions use their own threshold and authority. Controlled sharing of transaction, authentication and customer evidence can support all teams without exposing protected reporting details unnecessarily.

Testing should prove that one resolved incident task cannot silently close another unresolved assessment. Financial recovery should record the actual amount and source, including partial recovery. The lesson is that customer protection and investigation of proceeds are connected but distinct, and administrative status must preserve both.

Case 6: refunds redirect residual value after closure

A wallet is closed following a commercial decision. A later merchant refund arrives, and the system routes it to a newly supplied external account. The account name differs from the former wallet customer. Operations considers the refund low risk because it reverses an earlier purchase. The archive contains the purchase reference but no accepted authority for the new payout instruction.

Establish the customer's residual entitlement, actual refund, recipient instruction and applicable closure process. The refund may be legitimate, but moving it to another account is a separate value event. Determine whether the destination belongs to the customer, an authorised recipient or an unrelated person. A name difference can have a legitimate explanation, but it requires the relevant evidence rather than automatic acceptance or accusation.

The bank should decide how to hold, return or pay the residual value under the actual legal and service framework. If sanctions or another mandatory restriction applies, assess that separately. Commercial closure does not create permission to disregard outstanding customer funds, and it does not automatically prohibit every lawful refund. Record the ground, authority and execution of the decision.

The control repair should support post-closure events with retrievable identity and instruction history. Test late refunds, rejected payout, changed destination and partial amounts. The lesson is that product closure is not the end of the value lifecycle or the evidence obligations attached to residual positions.

Compare the cases by their decisive facts

The first case depends on funding relationships and actual cash-out. The second depends on changed features and legal conditions. The third depends on limit scope and reliable aggregation. The fourth depends on financial event status. The fifth depends on distinct victim, recipient and reporting decisions. The sixth depends on residual entitlement and payout authority. Those facts should shape the evidence plan. A universal request for more identification would not resolve all six.

Each case also contains benign alternatives or uncertainty. A family funding arrangement can be legitimate. A feature change can be lawful after proper assessment. A limit defect can originate in implementation. Failed funding can result from ordinary error. A recipient can be another victim. A post-closure account can be an authorised destination. Strong analysis tests those explanations and changes the conclusion when evidence supports them.

Convert cases into release evidence

Expected outcomes should be approved from the applicable requirements and case facts. Test the entire value chain, not only alert generation. Confirm the correct customer and instrument links, event population, applied limit, decision state, restriction scope and ledger result. Verify that corrected events retain originals and avoid duplicate movement of value. Test customer communication where status can be misleading.

Include negative cases that prove proportionality: legitimate third-party funding, supported shared devices, ordinary refunds, customers with several permitted instruments and valid product-tier changes. Include outages, delayed clearing and archive failures. The release evidence should explain tested scope, failed scenarios, repairs and residual limitations. A low fraud rate, secure tokenisation or balanced ledger is useful evidence within its own scope; readiness requires the maintained customer and value-control chain as well.

Worked wallet cash-out case

A fictional wallet receives repeated loads from unrelated cards, then transfers value to another wallet that withdraws cash. Investigate funding ownership, customer relationships, timing and purpose. Device linkage can guide inquiry but is not conclusive identity evidence.

Explain how fraud, AML and product-limit controls contribute different information and why tokenisation does not settle the laundering concern.

Exercise: establish what moved before deciding what it means

Use the fictional cash-out case to prepare a review pack for a bank that provides settlement services to the wallet issuer. The bank receives daily settlement files and a separate customer-level transaction feed. The issuer's own ledger is the record of each customer's claim. A programme manager distributes the wallet and provides customer support. A processor authorises card loads, while another provider executes cash withdrawals. These roles create several evidence sources; they do not create several independent versions of the same customer balance that can be added together.

Start with a transaction chronology. Record the time a card load was attempted, the authorisation result, whether value became available in the wallet, any later clearing or reversal, the transfer to the second wallet, and the cash payout. Give each event a status, amount, currency and identifier. Describe any currency conversion and fee separately. Ask whether the withdrawal depended on a provisional balance, whether the original load was ultimately settled, and whether the issuer or an external provider funded an intervening shortfall. An attempted load that failed cannot establish that illicit funds entered the wallet. A completed cash payout remains an economic event even if a later reversal removes the issuer's original funding.

The learner should produce both a customer view and a settlement view. In the customer view, identify the person entitled to the balance, any authorised user, each funding source, and the recipient of the transfer and cash. In the settlement view, identify which entities owe money to one another and how the daily net amount reconciles to underlying events. Explain the difference between those views in plain language. A net settlement that balances can coexist with missing information about who funded individual loads. Conversely, a customer record that appears complete cannot establish that a processor's financial file contains every event.

Now identify the facts that make the activity unusual. Repeated funding by unrelated persons, little apparent use for purchases, rapid transfers to a common recipient and immediate cash conversion are relevant together. State the uncertainty in each fact. The sources may be unrelated according to the current data rather than positively proven unrelated. Rapid movement can arise from a legitimate business or family purpose. A common recipient may operate a disclosed collection service. The conclusion should explain why the combination warrants inquiry and what evidence would support or weaken the hypothesis. It should avoid treating the red-flag pattern as proof of an offence.

Exercise: choose proportionate action with separate owners

Prepare three proposed actions: a customer inquiry, a restriction on a particular feature, and an escalation to the bank's financial-crime decision maker. For each, identify the person authorised to act, the evidence supporting the action, the operational consequence and the review point. Describe whether the issuer can restrict cash-out while retaining purchases, whether a bank-level restriction would affect the entire programme, and whether an individual card or wallet restriction would leave other instruments available. A control is useful only if its actual scope corresponds to the assessed risk.

The customer inquiry should request information relevant to the case. Ask about the relationship to the funding sources, purpose of the transfers, authority to use the cards and expected future activity. Select documents or other evidence that can substantiate those answers, taking account of the customer's circumstances and applicable requirements. Do not write an indiscriminate request for every possible document. Record the information already available so the support team does not ask the customer repeatedly for material held by another part of the programme. The issuer should evaluate the response against the transaction chronology and independent evidence, rather than treating a submitted document as automatic clearance.

For the feature restriction, distinguish a discretionary risk measure from a legal requirement to block or freeze. Describe the contractual basis, applicable legal constraints and customer communication route. Identify how a legitimate customer can obtain review and how the team will avoid disclosing protected investigation information. A sanctions-related legal hold, a fraud security restriction and an AML investigation can have different decision owners and release conditions. A case-management status called "restricted" should not silently substitute for those distinctions.

For escalation, set out known facts, missing facts and proposed next steps. Explain whether the bank has a direct customer relationship with either wallet holder, what information it can obtain through the issuer, and whether it has enough information to assess its own reporting obligations. Do not assume that the issuer's filing or decision to close an account discharges the bank's obligations. Equally, do not claim that every bank in the chain must make the same filing. The relevant institution must decide under the law that applies to it, with appropriate confidentiality and protection against tipping off.

Workshop: a product change that alters the risk perimeter

The programme began as a wallet for purchases from a limited group of merchants. The proposed release introduces transfers between customers and withdrawals through an agent network. The commercial team calls the change a convenience feature because the user interface still shows the same balance. The compliance team must assess the new movement of value and the provider's legal permissions. Existing low-risk assumptions may have relied on the absence of cash redemption or onward transfer. Retaining the product name does not retain those assumptions.

Create a before-and-after feature table. Include loading methods, funding-source ownership, person-to-person transfers, merchant payments, cross-border access, agent cash services, balance limits, transaction limits, account linking, refunds and closure. Identify which features are available to each customer group and in each jurisdiction. Include disabled functions if they can be enabled remotely by a partner. The release owner should be able to demonstrate that the approved configuration is the production configuration. A written policy does not prevent an unapproved cash-out feature if the processor accepts those instructions.

For each changed feature, identify the customer information needed, the transaction data required, the monitoring hypothesis, the operational decision and the accountable party. Adding customer transfers requires an identifiable sender and recipient relationship in the data, even when both balances sit in the same issuer ledger. Adding cash-out requires reliable payout status and recipient evidence, including the role of agents. Where a payment-information requirement applies, map its actual scope and implementation rather than importing a generic international threshold. Record when a proposed or transitional rule will become applicable; a future compliance plan is not evidence of current implementation.

The workshop output should include an explicit launch decision. An unresolved question may justify a restricted launch, a delay or an alternative design, depending on its importance. State the restriction in operational terms: which users, features, countries and channels are excluded, how the exclusion is enforced, and what evidence will allow reconsideration. An exception that merely says "monitor closely" provides no clear instruction to the processor or investigator. A temporary decision also needs an owner and an expiry or review event, so the exception cannot become permanent through inattention.

Acceptance tests that reveal substantive failures

Design an instrument-limit test with one customer and several legitimately issued cards. Attempt transactions through separate channels, including simultaneous requests, and verify whether the intended customer-level limit operates across all relevant instruments. Record which transactions were accepted, rejected or held, and whether the monitoring data captured every result. This tests a policy control, not a universal statutory limit. Repeat with two genuinely separate customers to show that the control does not incorrectly merge them solely because they use a shared address or family device.

Design a lifecycle test in which an authorised card load becomes provisionally available, a wallet transfer follows, and the load later reverses. The expected result should specify how the customer balance, issuer exposure, financial reconciliation and investigation record change. Include a partial reversal and a late arrival of the clearing event. Test whether a duplicate message creates duplicate value, a duplicate alert or neither. A good result retains the original sequence and later correction, allowing the investigator to reconstruct what the customer could do at each point.

Design a closure test in which a purchase refund arrives after the wallet has been closed. Verify the destination of the refund, the authority to pay it, the restrictions still in force, and the evidence retained. Attempt a request to send the refund to an unrelated account. The expected action must come from the applicable legal and contractual position, with referral to the authorised decision maker where necessary. The test should not require destruction of the money, automatic payment to any nominated person, or unconditional reopening of the customer relationship.

Design a data-loss test in which the settlement file arrives but the customer event feed omits cash withdrawals. Check whether reconciliation and completeness controls detect the omission before monitoring results are presented as complete. Show how the incident team identifies the affected period, assesses customer and reporting consequences, and recovers the missing events. Replaying a file is not enough if investigators cannot distinguish recovered activity from current activity or determine which previous decisions depended on incomplete information.

Review the answer against evidence, not vocabulary

The finished pack should enable a reviewer unfamiliar with the programme to understand the claim on value, the relevant parties, the transaction sequence, the reason for concern, the applicable decision boundaries and the next actions. Every important assertion should be linked to evidence or clearly labelled as an inference. A polished explanation using terms such as "high risk" and "enhanced monitoring" remains weak if it does not identify the missing funding relationship or show how the cash payout was established.

Assess whether the proposed controls are executable by the institution that owns them. A bank cannot directly alter an issuer's customer ledger merely because it provides settlement. A programme manager cannot release a bank's legal hold by changing a support ticket. Where a decision depends on another party, describe the instruction, acknowledgement, verification and escalation route. The practical close is a defensible decision and reliable follow-through, supported by evidence that remains available for later assurance.

Data and release requirements

Link customer, instrument, wallet, funding source, counterparty, rail and ledger event with clear status and timestamps. Retain original event references and reconciliation records so retries do not create duplicate value or duplicate alerts.

Acceptance tests cover failed funding, partial reversals, delayed clearing, refunds after closure, missing identities and cash-out restrictions. Product owners define features; compliance maps duties; fraud teams address credential abuse; operations reconcile balances; assurance tests coverage.

Effective controls understand the product's actual ability to store and move value and preserve the difference between technical security and financial-crime evidence.

Governance of a programme whose product can change remotely

A bank supporting cards or wallets should establish how the programme's actual features remain within its approved risk perimeter. Many changes occur through configuration rather than a visible new product launch. A processor can enable international usage, a programme manager can introduce an additional load channel, or an issuer can raise a transaction limit for a customer group. Each change can alter the ability to introduce, move or redeem value. Governance must therefore cover feature configuration, the authority to change it and the evidence that the resulting service corresponds to the approved design.

Maintain a register of material features and dependencies. Record the legal entity providing each regulated service, the programme manager, processor, distribution partners, agents, settlement bank and relevant subcontractors. Identify where customer information, authorisation events, clearing records, wallet balances and investigation files are held. The register should be specific enough to locate the owner of a missing cash-payout event without a long search through contracts. An organisational chart is helpful but does not replace the data and decision responsibilities embedded in the programme.

Separate accountability for accepting the programme relationship from accountability for individual customer and transaction decisions. Senior management may approve a programme's risk appetite and funding model. Compliance determines the application of relevant financial-crime requirements and advises on controls. Product and engineering teams implement features and maintain reliable records. Operations resolves exceptions and reconciliation breaks. Investigators assess cases, while the institution's authorised reporting function makes filing decisions. Independent assurance tests whether those responsibilities work in practice. Small institutions may combine roles, but the responsibilities and conflicts still need to be understood.

The programme approval should describe how the bank will obtain evidence if concerns arise. This includes contractually supported access, usable formats, response expectations, retention and continuity after termination. It also includes the actual ability to interpret the data. A right to receive a processor's event archive has little operational value if the bank does not possess the status definitions, currency conventions or identifier mappings needed to reconstruct a transaction. Material reliance on a partner should be assessed under the applicable legal framework, rather than justified by a contractual label alone.

Incentives and economics that can weaken control decisions

Examine how the programme earns revenue and how individuals are rewarded. An issuer may benefit from balances, a processor from transaction volume, a programme manager from customer growth and an agent from loads or cash services. Those incentives do not prove misconduct. They can, however, influence the treatment of exceptions, the willingness to pause a popular feature and the quality of customer information gathered at distribution points. The risk assessment should identify where a person who benefits from approval can also approve an exception or suppress evidence of a problem.

Consider a programme in which marketing promises immediate wallet access but customer evidence arrives through a separate partner system. The commercial pressure to activate balances may create a growing population whose features exceed their completed verification status. The important questions are which functions are available, what the law and approved policy require before those functions can be used, and whether the system enforces the required state. A monthly statement that "verification is in progress" cannot justify indefinite use of functions that require a completed control.

A credible exception process records the basis, scope, approving authority, compensating control, review point and exit conditions. It identifies whether an exception is permitted by law; a bank's risk appetite cannot waive a statutory requirement. For a discretionary policy exception, the approving person should understand the customer population and feature exposure, not simply the anticipated revenue. Exceptions that recur for the same partner, feature or control deficiency should be assessed together. Repeated short approvals can create a permanent unreviewed arrangement.

Programme economics also matter when a control requires meaningful operational capacity. A monitoring design may be sound on paper but ineffective if investigators cannot access evidence or resolve the resulting workload. Model the expected case volume, the proportion that needs partner information, the time required to obtain and review that information, and the skills needed for unusual product states. If the institution cannot support the proposed feature with reliable controls, consider a narrower service, better data arrangements or additional capacity. Increasing a nominal threshold merely to reduce a backlog changes the control hypothesis and requires a reasoned review.

Management information that distinguishes value, activity and evidence

Management should see measures that explain exposure and control performance. Report active customers and instruments separately, since one customer may hold several cards or wallets. Distinguish attempted, authorised, cleared, reversed and completed events. Show stored balances and gross movement of value alongside net settlement, rather than using one as a substitute for the other. Break down funding and redemption channels where they create materially different risks. Describe any population omitted from the measures and the reason for omission.

Useful data-quality measures include completeness of funding-source information, counterparty identity linkage, timing of clearing records, cash-payout status coverage and unresolved reconciliation breaks. Report the period affected and the practical consequence of each gap. A missing field that prevents an investigator from identifying the recipient is more consequential than a cosmetic formatting issue. Likewise, a high completion percentage can conceal a weak channel if the missing records are concentrated in cash-out or cross-border activity. Aggregate measures should be accompanied by relevant concentrations and exception populations.

Case measures should show age, evidence requests outstanding, decisions awaiting authority, restrictions awaiting implementation, and cases reopened because important information arrived later. Explain how these stages are defined. A decline in open cases may reflect stronger resolution, an inappropriate bulk closure or a loss of incoming data. Management should be able to distinguish those possibilities. Include the effect of rule changes and product changes on comparability over time, so an apparently improved alert rate is not presented without the changed coverage boundary.

Control effectiveness is better assessed through supported decisions and identified gaps than through raw alert counts. Track whether investigations obtained the evidence needed for their hypotheses, whether actions were implemented across all relevant instruments, and whether reporting decisions were documented appropriately. Include cases that were legitimately cleared. They demonstrate the institution's ability to avoid treating shared devices, family funding or high usage as automatic wrongdoing. Measures must respect confidentiality and access constraints while still allowing senior management to understand systemic weakness.

Independent assurance through an end-to-end sample

Select a sample that covers product features and lifecycle states, rather than taking only the newest open alerts. Include ordinary purchases, third-party loads, customer transfers, cash redemption, refunds, reversals and activity after restriction or closure. Include different customer groups, partner channels and currencies where relevant. A sample of a closed-loop product cannot demonstrate the controls for an open-loop wallet. State the selection basis and the limitations of the sample so the assurance conclusion does not exceed its evidence.

For each sampled event, trace the original instruction through authorisation, ledger posting, clearing, settlement and any correction. Confirm the customer and instrument linkage at the relevant time. Reconcile the event to the financial records and monitoring input. Where there was an alert, review whether the investigator could establish the actual movement of value and apply the correct legal and policy boundaries. Where there was no alert, test the relevant coverage hypothesis; absence of an alert is not itself an assurance failure or proof of effective control.

Test implementation of restrictions separately from the decision to impose them. A customer-level decision may need to cover multiple instruments, funding channels and partner systems. Determine whether a change was acknowledged and became effective, whether pending instructions were handled appropriately, and whether later refunds or reversals respected the applicable conditions. Include a controlled negative test that verifies legitimate activity remains available when the restriction is deliberately limited. This detects overly broad implementation as well as incomplete implementation.

Review evidence retention and reproducibility. The assurance reviewer should be able to reconstruct the status and information available when the original decision was made, not just today's corrected record. Check access logs, versioned customer information, event definitions and the link between the case and relevant records. Where the institution uses partner evidence, confirm that it remains accessible and interpretable. A screenshot of a current balance cannot replace the underlying chronology when the concern involved provisional value and a later reversal.

Tabletop: a compromised partner and an uncertain funding position

Run a fictional incident in which the processor reports an access compromise while the issuer discovers delayed clearing records for card loads. Some wallets have already transferred value and redeemed cash. The exercise should begin with known facts and explicit uncertainties. Identify the incident commander, fraud lead, financial-crime lead, product decision maker, reconciliation owner and legal adviser. Establish which customer functions can be limited safely, which financial records are authoritative and how affected periods and populations will be determined.

The initial decision should address ongoing exposure without assuming all affected customers are complicit. Credential compromise may require security action; missing clearing evidence creates financial and monitoring uncertainty; unusual cash conversion may require customer-level investigation. Preserve evidence before partner systems are rebuilt or overwritten. Describe how the institution will retain access to necessary data while applying appropriate security restrictions. Record communications and instructions to partners, including acknowledgements and the actual time changes took effect.

During the exercise, introduce a recovered batch of clearing events and an instruction to refund several customers through newly nominated accounts. The team must distinguish data recovery from validation of the refund recipients. It should reconcile recovered events, identify duplicate or conflicting records, revisit cases affected by earlier uncertainty and apply the relevant authority requirements to refunds. Recovery of the original card load does not by itself establish that any nominated destination is legitimate. Equally, the incident should not cause every legitimate customer balance to be treated as suspect.

Conclude with recovery criteria. Specify what must be true before each feature resumes, who can approve resumption and how the institution will verify the condition. Conditions may differ for purchases, transfers and cash-out. Include post-incident monitoring, backlog review, any required notifications and an assessment of whether previous reporting or customer decisions require reconsideration. The exercise is complete when it demonstrates an executable sequence of decisions, rather than merely listing teams that should attend a meeting.

Controlled exit and responsibility for residual value

Termination of a programme is a financial and operational process, not just a notice to stop onboarding. Identify remaining balances, pending authorisations, delayed clearing, expected refunds, disputes, reversals, legal holds and information requests. Determine the applicable treatment of customer value and the entities responsible for each action. Keep safeguarding, deposit protection, creditor rights and financial-crime restrictions distinct; their application depends on the product, provider and jurisdiction. Do not describe one regime as universally covering all stored value.

Agree how customers will receive relevant communications and how unresolved cases will be handled after the programme manager's ordinary support operation ends. Verify that contact and evidence channels remain usable. A partner's exit cannot erase the institution's applicable retention or reporting duties. Set out the archival format, access arrangements and responsible owner. Test a small sample of archived cases and events before accepting that the exit obligations have been met.

The governing body should receive a closure pack showing financial reconciliation, residual obligations, customer outcomes, unresolved restrictions and the evidence supporting completion. Any remaining exposure needs a named owner and a review mechanism. A programme can cease trading while the institution still has work to complete. Responsible closure recognises that residual value and historical evidence continue to matter after the user interface has disappeared.

References and further reading

Reviewed 2 October 2026. FATF provides international standards; applicable national law determines binding duties. The operating examples are fictional teaching cases.

• FATF Recommendations, updated June 2026 — relevant anchors: 10, 15 and 16.
• FATF prepaid-card and mobile-payment guidance

The 2013 sector guidance is non-binding and predates later FATF standard revisions, including the 2025 changes to Recommendation 1. FATF expressly advises reading it alongside current Recommendations and more recent risk-assessment and financial-inclusion guidance. It is a source of practical context, not a complete statement of current national obligations.