Cash, Card, Merchant, E-Money and Prepaid Typologies

A useful way to understand product typologies is to stop asking only, “Is this customer high risk?” and ask a second question: what can this product actually do? The same customer can look completely different when using cash, a debit or credit card, a merchant-acquiring relationship, an e-money wallet or a prepaid instrument. Each product creates its own data, timing, anonymity, velocity, acceptance and redemption characteristics. Those mechanics change both the opportunities available to criminals and the evidence available to the institution.

That is why a single transaction-monitoring rulebook applied uniformly across all rails is rarely enough. A cash control needs to aggregate deposits across time, channels and related parties. A card control may need to link low-value testing with later exploitation. An acquirer needs to compare live merchant activity with the business it actually underwrote. An e-money issuer needs visibility over funding, wallet-to-wallet movement and redemption inside its own ecosystem. A prepaid programme may need programme-specific controls over issuance, loading, transferability, international use and cash-out.

The point is not that one product is inherently “bad” while another is “safe”. Risk depends on features, customer base, geography, distribution model, transaction limits, verification level, funding methods, redemption options and the institution’s actual control environment. FATF’s risk-based approach is built around that idea: controls should be proportionate to the risks presented by customers, products, services, transactions and delivery channels rather than driven by labels alone.

Product-specific financial crime risk map comparing cash, cards, merchant acquiring, e-money and prepaid instruments.

Cash: the pattern often matters more than the deposit

Cash remains important because physical currency can enter or leave the financial system without the payer and payee metadata that normally accompanies an electronic transfer. That does not make every cash customer suspicious. Restaurants, retailers, transport businesses, market traders and many other legitimate sectors can have genuine cash flows. The monitoring challenge is therefore to distinguish activity that is plausible for the customer from activity that suggests deliberate fragmentation, unexplained cash intensity, rapid conversion or coordination between several people.

A classic example is structuring. The risk is not simply “a deposit below a threshold”. It is a pattern in which transactions appear deliberately organised to avoid a reporting, recordkeeping or internal-control trigger. Legal thresholds differ across jurisdictions, so a global system should not embed one country’s reporting amount as if it were universal. Instead, the control architecture should support configurable jurisdiction and legal-entity rules while also maintaining behavioural aggregation independent of those legal thresholds.

Useful cash-monitoring dimensions include the customer, account, related parties, branch, ATM, teller, deposit channel, amount pattern, rolling time window and subsequent use of funds. If several people make cash deposits into the same beneficiary account at different locations over a short period, the relationship between the deposits may be more important than any one deposit. If cash is credited and almost immediately withdrawn, transferred or converted into another product, the timing can add context. If a business claims high cash takings but its observed supplier payments, seasonality and account history do not support that scale, the discrepancy may justify review.

Investigators should still avoid reverse engineering a criminal story from an alert. A cash-intensive business can have unusual but legitimate trading conditions. A customer may change branches for convenience. A family may legitimately make deposits for a common purpose. The investigation should establish what is known, what is inferred, what evidence supports the explanation and whether unresolved facts meet the institution’s escalation or reporting standard under applicable law.

Cash aggregation model showing how deposits across days and channels are combined before an evidence-led decision.

Cards: fraud signals and AML signals overlap, but they are not identical

Card activity creates a different analytical problem. Authorisation happens quickly, transactions can be repeated at high velocity, and fraud controls may act before a financial-crime investigator ever sees the activity. That makes card data highly useful, but it also creates a common mistake: treating a fraud event as automatic proof of money laundering.

Card-not-present abuse can involve stolen credentials, account takeover or social engineering. Low-value authorisations may be used to test whether compromised credentials are valid before higher-value purchases are attempted. Useful evidence can include authorisation outcome, merchant ID, merchant category, channel, e-commerce indicator, authentication result, device information where lawfully available, token or wallet state, decline sequence, velocity and deviation from the cardholder’s normal behaviour.

The AML relevance depends on what follows. Fraud proceeds may be moved through mule accounts, merchant fronts, refund abuse or other channels. A confirmed victim should not be treated as a criminal merely because the account participated in a fraud flow. Likewise, a recruited or coerced mule requires an evidence-led assessment rather than an automatic guilt label. Fraud prevention, reimbursement, payment recovery, account restriction, customer vulnerability handling and suspicious-activity reporting are related processes, but they have different objectives and decision standards.

A good card-control architecture therefore keeps the signal lineage. An analyst should be able to see what happened during authorisation, which fraud rule fired, what authentication occurred, whether the transaction settled, whether a dispute or chargeback followed, whether related accounts or merchants appear elsewhere, and which later AML decision relied on which evidence.

Card testing-to-exploitation sequence showing the evidence used to link low-value probes with higher-risk activity.

Merchant acquiring: know the merchant you actually process for

Merchant acquiring introduces risk on the acceptance side of the card ecosystem. The acquiring institution may have performed due diligence on a merchant that originally appeared to sell one set of goods or services, while the merchant later processes transactions that no longer fit that profile. The relevant question is not merely whether the merchant’s name appears on a sanctions or watch list. It is whether the commercial reality still matches the business the acquirer agreed to support.

JMLSG’s UK sectoral guidance, for example, describes merchant acquisition as a relationship in which the acquirer processes card transactions for a merchant and highlights the importance of understanding expected turnover and average ticket value at the start of the relationship. That is UK industry guidance rather than a universal global rule, but the underlying risk principle is broadly useful: an expected merchant profile gives monitoring something meaningful to compare with live behaviour.

Potential risk signals can include unexplained changes in processing volume, ticket size, countries, channel mix, refunds or chargebacks; inconsistency between the merchant category and actual business activity; ownership or control changes; settlement to unexpected beneficiaries; or opaque payment-facilitator and sub-merchant arrangements. None of those signals proves transaction laundering. They create questions that need evidence.

For payment facilitators and aggregators, the data model matters enormously. If an acquirer sees only a master merchant while meaningful risk sits at the sub-merchant level, the control may have a structural blind spot. Requirements should therefore define which sub-merchant identifiers, business attributes, transaction fields and settlement relationships must be available, who owns their quality, and how a case analyst retrieves them.

The outcome does not always have to be immediate termination. Depending on evidence, contract, scheme rules, risk appetite and applicable law, responses may include enhanced monitoring, additional due diligence, restrictions, reserve or settlement controls where commercially and legally appropriate, or exit. The compliance function should not use AML as a substitute for scheme, credit or commercial governance; the evidence and authority for each action should remain clear.

Merchant acquiring lifecycle from onboarding and expected profile through live processing, anomaly review and a documented decision.

E-money: the institution may see internal value movement that banks outside the ecosystem cannot

E-money and wallet products can create very rich internal data. A wallet provider may be able to see account creation, device relationships, funding source, wallet-to-wallet transfers, merchant spend, redemption, beneficiary relationships and product-limit events in one environment. A bank that only sees the external funding or redemption leg may have far less context.

The EBA’s consolidated ML/TF risk-factor guidelines provide a useful European example of product-specific thinking. They identify e-money risk factors such as customers purchasing several products, frequent reloading or cash withdrawals without an economic rationale, transactions repeatedly just below relevant limits, use by multiple unidentified persons, frequent changes in identification data, or use inconsistent with the product’s intended purpose. Those examples apply in the EU regulatory context and should not be copied mechanically into other jurisdictions, but they illustrate how product features and actual behaviour are analysed together.

A practical monitoring model should follow the wallet lifecycle. First, how is value loaded? A bank transfer, payment card, cash agent and third-party funding source carry different evidence. Second, how does value move inside the ecosystem? Multiple wallets funded from a common source, many accounts using the same device infrastructure, rapid pass-through chains or concentrated beneficiary networks may deserve investigation when inconsistent with expected use. Third, how is value redeemed or spent? Rapid cash-out, concentrated ATM use, unusual merchant categories or immediate onward transfer can add context.

Tiered verification and product limits need careful legal scoping. Some jurisdictions permit simplified or lower-friction arrangements for particular lower-risk products or thresholds; others structure the regime differently. The control should therefore store the customer’s verification tier, applicable product permissions, legal entity and effective rule version rather than assume one global definition of “low risk”.

E-money wallet lifecycle showing loading, internal transfer and redemption evidence with jurisdiction-aware controls.

Prepaid products: programme features determine risk

“Prepaid” covers many different arrangements. A closed-loop gift card, payroll card, travel card and reloadable open-loop payment product are not operationally identical. Transferability, international use, anonymous or identified access, load source, reloadability, balance limits and cash-out functionality all affect risk.

The United States provides a clear example of why jurisdiction must be explicit. FinCEN’s prepaid-access rule defines covered prepaid programmes, providers and sellers for Bank Secrecy Act purposes and includes specific exclusions and conditions. Those US thresholds and definitions are not global standards and should never be coded into a worldwide product model as universal rules. They are useful as an illustration of how regulators differentiate prepaid products according to features and control over the programme.

Monitoring can examine bulk acquisition, repeated loading, common funding sources, third-party loads, linked devices, rapid redemption, ATM concentration, international use and multiple instruments connected to the same beneficiary or programme. Corporate and payroll programmes require a different baseline from consumer gift cards. A large order of cards may be completely normal for an employer but unusual for an individual consumer. Risk assessment should therefore operate at both instrument and programme level.

Gift-card scam scenarios also need care. A victim who has been manipulated into purchasing gift cards may show behaviour that looks unusual, but the customer may need protection rather than suspicion. Front-line intervention, fraud handling and AML analysis should exchange useful evidence without collapsing their decisions into one automated label.

Product data and system touchpoints

Product-aware monitoring is only as good as the data available to it. Cash scenarios may depend on teller, branch and ATM data that never reaches the generic payment hub. Card scenarios may need authorisation and authentication fields stored in separate card platforms. Merchant monitoring may require acquiring and settlement data plus KYB information held in onboarding systems. Wallet monitoring may need internal ledger and device relationships unavailable to the bank’s enterprise transaction-monitoring feed. Prepaid programmes may be operated partly by programme managers, processors or distributors outside the core bank.

For a business analyst, this means the requirement cannot stop at “monitor cards” or “monitor wallets”. The requirement should state the business event, source system, field, identifier, timestamp, entity key, retention need, lineage, expected completeness and action when the data is unavailable. It should also say whether the control is pre-transaction, near-real-time, post-event or periodic, because the operational outcome changes with timing.

Entity resolution is particularly important. A customer ID, card number token, merchant ID, terminal, device, wallet ID, programme ID and beneficiary account may each live in a different domain. Cross-product investigation requires a controlled way to link them without treating weak matches as facts. Match confidence, provenance and effective dates should be visible to the analyst.

From alert to case and investigation

An alert is a prompt to review evidence, not a final judgement. Product alerts should preserve the typology that generated them and the data window used. During triage, the reviewer asks whether the activity can be explained from reliable customer and product context. If not, the case may be enriched with related accounts, merchants, devices, funding sources, prior alerts, customer contact where appropriate and other lawful internal or external information.

The investigation should separate facts from hypotheses. For example, “five wallets were funded by one card in twenty minutes” is an observed fact. “The wallets are a mule network” is an analytical hypothesis that requires supporting evidence. That distinction matters for quality assurance, customer treatment and reporting.

If the institution concludes that suspicious activity reporting may be required, the decision should follow the law and procedure applicable to that entity and jurisdiction. US SAR rules, UK SAR arrangements, Australian SMR requirements and other national regimes differ in thresholds, timing, confidentiality and reporting mechanics. A global platform should route the case to the correct legal-entity workflow rather than present one reporting standard as universal.

Roles and governance

Product risk is usually shared across several teams. Product owners understand intended use and customer journeys. Operations teams understand exceptions and customer impact. Fraud teams may own immediate loss prevention. AML teams assess laundering and other financial-crime risk. Merchant-risk or acquiring teams understand business models, scheme requirements and settlement exposure. Data and technology teams own source feeds, decision engines, case platforms and auditability. Legal and compliance functions interpret obligations and approve policy where required.

Clear ownership matters most when signals cross boundaries. A card fraud event may create an AML referral. A merchant investigation may identify sanctions or fraud concerns. An e-money wallet may depend on third-party onboarding. The operating model should define who receives the signal, who owns the decision, which evidence is transferred and how duplicated or conflicting cases are reconciled.

Governance should also look at effectiveness rather than alert volume alone. Useful questions include whether material product risks are covered, whether required data is complete, whether scenarios behave as intended, whether outcomes differ materially by product or customer segment, whether false negatives are discovered through lookbacks or investigations, and whether changes in product features trigger control reassessment.

Failure modes to watch for

A common failure is product blindness: applying bank-transfer rules to products whose mechanics are different. Another is data blindness: assuming a monitoring system sees fields that remain in the card processor, merchant platform or wallet ledger. A third is decision collapse: allowing a fraud flag, merchant reserve action or sanctions result to become an AML conclusion without independent assessment.

Over-control is also a real risk. Cash-heavy customers can be unfairly restricted when the institution lacks a good understanding of legitimate business models. E-money and prepaid products often support customers who may have limited access to traditional banking. A rule that treats unfamiliar behaviour as suspicious by default can create financial exclusion without materially improving detection.

The opposite failure is excessive reliance on low thresholds or known typologies. Criminal behaviour adapts, and legitimate customer behaviour changes. Controls need scenario governance, segmentation, quality assurance and periodic review of both detected and missed cases.

BA, architecture and testing considerations

For delivery teams, each product control should be traceable from risk statement to requirement, source data, logic, alert, case decision and evidence. Acceptance criteria should test the relationship between transactions, not just whether one field exceeded a threshold. Cash tests should include aggregation across branches and days. Card tests should include probe-to-exploitation sequences and legitimate high-frequency spending. Merchant tests should include profile changes and benign seasonal growth. Wallet tests should include internal transfers and ordinary inclusion use cases. Prepaid tests should distinguish consumer and corporate programme patterns.

Testing should use synthetic, masked or formally approved test data in controlled environments. Production mystery transactions should not be introduced merely to prove that a control works. Failure-mode testing should cover missing source feeds, late events, duplicate events, clock or timezone differences, identifier changes and partial third-party data. The expected degraded behaviour should be defined in advance rather than improvised during an outage.

A strong audit trail should answer six questions: what data arrived, what version of the rule or model evaluated it, what signal was produced, what enrichment the analyst saw, what decision was made, and who approved or changed that decision. Without that chain, the institution may be able to detect risk but still struggle to explain its control to auditors, supervisors or customers.

Practical mental model

The most useful summary is simple. Cash risk is about aggregation and source. Card risk is about sequence, authentication and counterparties. Merchant risk is about whether processing still matches the business that was underwritten. E-money risk is about how value enters, moves internally and exits. Prepaid risk is about programme features, loading, transferability and redemption.

The products overlap, but the evidence is not interchangeable. Good financial-crime control design respects those differences while joining them at investigation level when the same customer, merchant, device, beneficiary or value flow crosses several rails.

Operational deep dive: how product mechanics change the investigation

The base chapter explains the main typologies. This deep dive focuses on a harder operational question: what evidence should an investigator expect to exist for each product, and what can that evidence genuinely prove? Cash, cards, merchant acquiring, e-money and prepaid products leave different traces. A strong investigation uses those traces without pretending that missing data, a threshold breach or a familiar typology is proof of criminal conduct.

Cash: reconstruct the pattern before interpreting it

A cash investigation normally begins with aggregation. The reviewer should first establish the relevant population: deposits and withdrawals for the customer, connected accounts where policy permits, branch and ATM activity, known third-party depositors, the time window under review and the subsequent movement of funds. Only after that population is stable should the analyst interpret whether the pattern is consistent with the customer’s expected activity.

For a business, useful context can include sector, expected turnover, seasonality, usual suppliers, payroll pattern, card-acquiring receipts and previous account behaviour. A restaurant or market trader can legitimately generate frequent cash deposits. A professional-services company with no obvious cash business may require a different explanation. The comparison should be based on what the institution knows about the customer, not on stereotypes about an industry.

Structuring is frequently misunderstood. A series of deposits below a reporting or internal threshold can be relevant, but amount alone does not establish intent. The analyst should consider timing, location, depositor relationships, repeated amount patterns, customer explanations and any evidence that the activity was deliberately arranged to avoid a particular requirement. Because reporting and recordkeeping rules differ across jurisdictions, the case tool should identify the legal entity and rule set that apply rather than display one global cash threshold.

Cross-border physical-cash movements can also matter, but banks do not universally receive border declaration or seizure data. Where an institution lawfully receives such information from a customer, public source, government request or permitted intelligence channel, it can be considered alongside account activity. Where that information is not available, the investigation should record the limitation rather than infer that a declaration did or did not exist.

A useful review sequence is: establish the cash population, compare it with the expected customer profile, identify relationships between depositors and beneficiaries, examine what happened after cash entered the account, request proportionate supporting information where appropriate, and then decide whether the unexplained facts meet the institution’s escalation standard.

Cards: distinguish authentication, fraud and laundering questions

Card data can be unusually rich because several events may exist around one purchase: authorisation request, authentication result, issuer decision, clearing, settlement, dispute and chargeback. Those events may live in different systems and use different identifiers. A financial-crime case should preserve the linkage between them rather than rely only on the final posted transaction.

Low-value card testing is one example. Attackers can make small or repeated authorisation attempts to learn whether credentials are valid before attempting larger purchases. The useful evidence is the sequence: common card or token, merchant, device, channel, time pattern, authentication result and later exploitation. A single small transaction is weak evidence by itself.

Physical-card compromise can also create clusters around a terminal, ATM or merchant location. The investigator may see several unrelated customers who later experience suspicious card use after interacting with a common point. That pattern can support a fraud investigation and may lead to broader financial-crime review if proceeds, merchants or beneficiary accounts create additional concern. The bank should avoid making technical claims it cannot support. For example, transaction data may suggest a common compromise point without proving exactly which physical device or technique was used.

Fallback or magnetic-stripe transactions can be relevant where the product and network support them, but the meaning depends on terminal capability, country, card configuration and legitimate technical failure. A high fallback rate is therefore a signal for investigation, not automatic evidence of card cloning or terminal manipulation.

The most important governance point is that authentication answers a narrow question: whether the transaction met the authentication method applied to it. It does not prove that the customer was not deceived, that the merchant was legitimate or that the resulting movement of funds had a lawful purpose. Fraud and AML teams may share evidence while reaching different decisions.

Merchant acquiring: investigate the gap between expected and observed business

Merchant acquiring investigations are strongest when they begin with the approved merchant profile. The reviewer should know what business activity was declared and verified, which owners and controllers were identified, which merchant category was assigned, what turnover and ticket size were expected, which countries and channels were anticipated and where settlement proceeds were expected to go.

Live processing can then be compared with that baseline. Large increases in volume, new geographies, material changes in ticket size, unusual refund behaviour, settlement to unexpected beneficiaries or a mismatch between website activity and payment processing can all justify review. None is conclusive on its own. A seasonal merchant may grow quickly for legitimate reasons. A business can launch a new product. A website may be stale. The purpose of monitoring is to surface the mismatch so that it can be understood.

Payment facilitators and aggregators add another layer because the contractual merchant visible to the acquirer may represent many underlying sellers. The risk question is whether the acquirer has the data and contractual rights needed for its role: identification of relevant sub-merchants, business information, transaction linkage, settlement information and escalation access when required by the model and applicable rules. The exact obligations differ across jurisdictions, card-scheme arrangements and business models, so the chapter treats transparency as a control-design principle rather than a universal legal formula.

When the evidence remains unexplained, several decisions may follow. Merchant-risk teams may consider contractual or scheme action. Fraud teams may investigate cardholder harm. AML teams may consider whether the facts create suspicion under the applicable reporting regime. Credit or settlement-risk teams may address financial exposure. A good case preserves those decisions separately so that one team’s action is not misrepresented as another team’s legal conclusion.

E-money: internal movement can be more informative than the bank transfer

An e-money or wallet provider may observe activity that an external bank cannot. One bank transfer can fund a wallet, after which value may move several times inside the platform before being spent or redeemed. If the institution monitors only external funding and cash-out, it may miss the relationships that make the activity understandable.

A wallet investigation should therefore reconstruct three stages. First, load: who or what funded the value, by which method and under which customer or product limits? Second, move: did value remain with the customer, move to a small number of known contacts, disperse across many wallets or pass rapidly through several accounts? Third, redeem or spend: where did value ultimately go, and does that outcome fit the product’s intended use and the customer profile?

Device, funding-source and beneficiary relationships can be useful, but their evidential strength varies. Several family members can legitimately share a device or payment card. A business may fund employee wallets. A merchant may serve many unrelated users. The case should therefore preserve whether the relationship is verified, inferred or simply an analytical lead.

The EBA risk-factor guidance is a useful European example because it discusses product features and behaviour such as multiple products, repeated loading, transactions close to applicable limits and activity inconsistent with intended use. Those examples should not be transformed into global rules. Other jurisdictions may define e-money, stored value, prepaid access and customer-due-diligence options differently.

Prepaid: understand the programme before the instrument

Prepaid investigations often fail when the reviewer treats every card as the same product. Programme design matters. A closed-loop gift card, travel card, payroll card and general-purpose reloadable product have different users, funding methods, limits, cash-out possibilities and expected transaction patterns.

The reviewer should therefore identify the programme type before interpreting the activity. Relevant questions include whether the product is reloadable, transferable, usable internationally, capable of ATM withdrawal, linked to a named customer, funded by third parties or distributed through agents. Those characteristics help explain both risk and legitimate use.

Programme-level aggregation can reveal relationships that are invisible at card level. Many instruments may be funded from the same account, loaded through the same distributor, activated from common devices or redeemed through a concentrated set of locations. That does not automatically make the programme suspicious, but it can justify examination of the commercial explanation and the controls around issuance and distribution.

US FinCEN’s prepaid-access rule is one jurisdiction-specific example of how regulation distinguishes programmes according to features and control. Its definitions, exclusions and thresholds should not be reused as a universal template. A global product architecture should instead store the jurisdiction, legal entity, programme type and applicable rule version so that the right obligations can be applied locally.

Product-specific data lineage

Investigators often assume that if a transaction exists somewhere in the institution, the monitoring platform must have received it. That assumption is dangerous. Cash depositor information may remain in branch systems. Card authorisation attempts may remain with a processor while only settled transactions reach the enterprise AML platform. Merchant KYB data may sit in an acquiring application. Wallet-to-wallet transfers may never touch the core banking ledger. Prepaid programme data may be held by a processor or programme manager.

The control owner should therefore maintain a source-to-case lineage for the data elements that matter. The lineage should identify the source event, source system, transformation, delivery frequency, customer or product key, reconciliation method and case field. It should also document known exclusions. An investigator who knows that authorisation declines are not available can reason differently from one who wrongly assumes the absence of declines means they never occurred.

Completeness assurance should match the product. Branch and ATM cash totals can be reconciled to source systems. Card authorisation or settlement populations can be compared with processor counts. Merchant transaction and settlement populations can be reconciled with the acquiring platform. Wallet internal transfers can be reconciled to the wallet ledger. Third-party feeds should have documented delivery and exception controls.

Reviewer routing and product expertise

Some product cases require specialist knowledge, but that does not mean every alert belongs permanently in a specialist queue. A scalable operating model can train general investigators on standard product patterns and define escalation criteria for complex merchant structures, multi-product networks, unusual legal questions or cases with material customer-impact decisions.

Routing should be based on observable complexity rather than vague labels. Useful factors can include the number of products involved, the depth of entity relationships, jurisdictional complexity, the presence of a payment facilitator or programme manager, and whether specialist source data must be interpreted. Capacity and ageing should still be monitored so that specialist queues do not become risk backlogs.

Quality assurance should examine reasoning, not only the final disposition. Did the reviewer understand the product mechanics? Did they use the available data? Did they distinguish a fraud signal from an AML conclusion? Did they document missing information? Did they apply the correct legal-entity workflow? Those questions reveal whether the control is functioning as intended.

Machine-assisted detection: useful, but not self-justifying

Rules are not the only way to detect product risk. Institutions may use statistical models, anomaly detection, graph analysis or other machine-assisted methods to identify unusual relationships or patterns. The model choice should follow the control objective rather than fashion. A transparent aggregation rule may be better for a clear cash pattern, while graph analysis may help where a wallet network contains many related accounts.

Whatever technique is used, governance should cover input data, intended use, performance measures, validation, change control, explainability appropriate to the decision, monitoring for drift and human review where required. A model score is evidence about a pattern, not proof of criminality. The case should preserve the model version and the factors or supporting information that reviewers are expected to consider.

Segment-level testing can also be important. A model that performs well overall may work poorly for a particular product, geography or customer segment. Where fairness or customer-outcome risks are relevant, institutions should test whether control design creates unjustified disparities and whether those differences can be explained by legitimate risk factors and policy.

The investigation standard across all five products

The same discipline applies even though the products differ. Reconstruct the relevant population. Understand the product and customer baseline. Identify what changed. Link related events using evidence with known confidence. Record data limitations. Seek proportionate explanation where appropriate. Separate fraud, contractual, sanctions, AML and customer-protection decisions. Apply the reporting and escalation rules of the correct legal entity and jurisdiction. Preserve the audit trail.

That approach is more useful than memorising a list of red flags. Typologies help reviewers know where to look; product mechanics and evidence determine what the institution can responsibly conclude.

Advanced practice: product controls, cross-rail evidence and governance

The base chapter explains why cash, cards, merchant acquiring, e-money and prepaid instruments need different monitoring logic. This section goes one level deeper into the operating model: how product-specific controls are designed, how data moves between platforms, how cases cross rail boundaries and how governance avoids both under-control and unnecessary customer harm.

Design the control around the product lifecycle

A strong control starts with the lifecycle rather than the alert engine. For cash, the lifecycle includes deposit or withdrawal, channel, branch or ATM, customer context and subsequent use of funds. For cards, it includes authorisation, authentication, settlement, dispute and any later fraud or AML referral. For merchant acquiring, it begins with KYB and underwriting, continues through live processing and settlement, and may end with enhanced monitoring, restriction or exit. For e-money and prepaid products, the lifecycle includes issuance, verification tier, loading, internal transfer, spend and redemption.

Mapping the lifecycle first prevents a common design error: putting a monitoring rule around the fields that happen to be easiest to obtain instead of the fields that are actually needed to understand risk. The requirement should therefore identify each business event, its source system and the control point at which the institution can still act.

Keep product risk and legal obligations separate

Product features create risk, but legal obligations are jurisdiction-specific. A reloadable prepaid product may be treated differently from a closed-loop gift card. An e-money issuer may have different customer-due-diligence options from a bank deposit product. Cash reporting thresholds, suspicious-activity reporting rules and confidentiality requirements vary across legal regimes.

The architecture should therefore separate three layers. The first is the product-risk layer: what the instrument can do and how it may be misused. The second is the policy layer: what the institution has chosen to control within its risk appetite. The third is the legal layer: what the relevant entity is required to do in the jurisdiction where it operates. Mixing the three into one rule makes change management fragile and can cause a local obligation to be presented as a global standard.

Cross-product entity resolution

Criminal activity often crosses products. Cash can be deposited into an account, moved to a card-linked wallet, transferred to another wallet and then redeemed. A merchant may receive card settlements into an account that also shows unusual cash activity. A prepaid card may be funded from an account connected to several other cards or wallets.

Cross-product analysis depends on entity resolution. Useful keys can include customer ID, account ID, tokenised card identifier, merchant ID, terminal ID, wallet ID, device identifier, programme ID, beneficiary account and corporate ownership links. Not every match has the same evidential strength. A shared customer ID is stronger than a weak address match. A reused device may be meaningful, but shared household or business equipment can also create legitimate overlap.

For that reason, the case platform should record the match type, confidence, source, effective date and whether the relationship was system-derived or analyst-confirmed. A graph is valuable only when reviewers can distinguish verified relationships from analytical leads.

Product segmentation and scenario calibration

Calibration should reflect legitimate product behaviour. Cash-intensive retailers cannot be compared blindly with salaried personal customers. Corporate travel-card programmes behave differently from consumer debit cards. A payment facilitator processing thousands of sub-merchants should not be benchmarked against a small single-store merchant. A low-value wallet designed for domestic payments has a different expected profile from a multi-currency travel wallet.

Segmentation should be explainable and governed. Each segment needs a clear business definition, known data coverage and a documented reason for different thresholds, models or review processes. Changes in the customer or product profile should be able to move an account or merchant into a different segment without losing the history required to understand earlier alerts.

Calibration should use both positive and negative examples. Testing only known suspicious cases can create controls that detect risk but generate too much friction for legitimate users. Testing only historical alerts can also hide false negatives because the institution does not know what it never detected. Lookbacks, confirmed external events, fraud referrals, law-enforcement feedback where lawfully available and carefully designed synthetic scenarios can all contribute to assurance.

E-money and prepaid governance

E-money and prepaid programmes often involve several parties: issuer, programme manager, processor, distributor, agent, card network and funding bank. The risk model should show who performs onboarding, who holds customer information, who sees internal transfers, who can block or restrict value and who files any required regulatory report.

Contractual outsourcing does not remove the institution's need to understand control effectiveness. Service-level agreements should cover data delivery, incident escalation, access for investigations, record retention, audit rights and change notification. If a processor changes a data field or an agent model expands into a new geography, the monitoring design may need reassessment.

Programme-level reporting is especially important for prepaid products. Instrument-level alerts may miss a pattern in which many cards are loaded from related sources and redeemed through a common set of locations. The programme view should therefore include issuance volumes, verification tiers, load sources, transfer functionality, international use, cash-out capability, exceptions and concentration indicators.

Merchant acquiring and sub-merchant transparency

Acquiring controls depend on understanding the actual merchant population. Where a payment facilitator or aggregator model is used, the acquirer should understand what sub-merchant information it receives, how quickly it is updated and whether investigators can obtain enough detail to explain suspicious processing.

Monitoring should compare live behaviour with the merchant profile created at onboarding: business model, MCC, expected turnover, average ticket size, geographies, channels and settlement pattern. A mismatch is not proof of misconduct. It is a reason to ask whether the merchant has legitimately changed its business, whether the profile is stale or whether the activity is being used for an undisclosed purpose.

Governance should also distinguish AML concerns from scheme and commercial concerns. High chargebacks may be a fraud or merchant-quality issue without being money laundering. Conversely, a low-chargeback merchant can still create financial-crime risk if it processes transactions for activity outside the declared business model. The case record should make those distinctions visible.

Cash and card data quality controls

Cash controls can fail because transaction feeds omit branch, teller, ATM or depositor information needed for aggregation. Card controls can fail because the enterprise monitoring platform receives settled transactions but not authorisation attempts, authentication results or decline sequences. Data lineage should identify those limitations explicitly.

Completeness testing should therefore be product-specific. A cash feed can be reconciled against branch and ATM source totals. Card authorisation populations can be reconciled against processor counts. Merchant settlement records can be compared with acquiring platform totals. Wallet internal transfers should be reconciled to the platform ledger, not only to external bank movements.

When data is late or unavailable, the control needs a defined response. Some scenarios may be able to wait for the feed; others may need degraded logic or operational escalation. The response should be agreed in advance with product, operations, compliance and technology owners rather than improvised during an incident.

Cross-rail case assembly

A cross-rail case should be created because evidence connects activity, not simply because multiple alerts exist. Useful triggers can include a common beneficial owner, customer, device, beneficiary, merchant, funding source or tightly linked sequence of value movements. The case should preserve the originating alerts so reviewers can see why each rail produced concern.

The investigation timeline should combine business events in a common time basis and handle timezone differences explicitly. This is especially important when card authorisations, wallet transfers and core banking postings use different timestamps. Poor time normalisation can create false sequences or hide real ones.

The disposition should still remain granular. A reviewer may close one card alert as explained while keeping the broader merchant or wallet case open. Closing the parent case should not erase the underlying rationale, and reopening should not require recreating the evidence from scratch.

Outsourcing and specialist review

Product expertise matters, but specialist queues can become bottlenecks. A practical model is to route standard cases to trained generalists with escalation to product specialists when complexity, value, vulnerability, network depth or legal consequence warrants it. Reviewers should be trained on the mechanics of the products they assess, not only on generic AML terminology.

Where review is outsourced, quality assurance should test reasoning as well as throughput. Sampling should check whether the reviewer understood the product, used the available data, distinguished fraud from AML questions, documented uncertainty and followed the correct jurisdictional workflow. Data access for outsourced teams should follow least-privilege and applicable cross-border data restrictions.

Change management

Product changes should trigger control review. New funding methods, higher limits, instant wallet transfers, new countries, new merchant categories, additional cash-out channels or a new payment-facilitator model can all alter risk. The change process should include financial crime before launch rather than relying on post-launch alerts to reveal the new exposure.

A useful implementation control is a product-to-control matrix showing the feature, risk statement, source data, monitoring logic, operating owner, legal or policy dependency, test evidence and review date. That matrix becomes a practical bridge between product management, compliance, architecture, engineering, testing and operations.

Practice close: product-control requirements and testing

This section converts the chapter into practical delivery artefacts for business analysts, architects, developers, testers, operations and financial-crime control owners. The emphasis is on proving that each product is monitored according to its mechanics, while keeping testing controlled, reproducible and safe.

BA checklist before accepting the design

For cash, the requirements should identify the aggregation dimensions that matter: customer, related party, account, branch, ATM or teller channel, rolling time period, deposit and withdrawal relationship and expected cash profile. The design should not rely only on one transaction amount or one jurisdictional threshold.

For cards, the requirements should identify whether the control uses authorisation attempts, settled transactions or both. Where relevant, it should capture authentication outcome, merchant and terminal identifiers, channel, decline sequence, token or wallet state and device or location evidence that the institution is legally permitted to use. If the monitoring platform receives only settled card transactions, that limitation should be explicit.

For merchant acquiring, the design should connect the approved merchant profile with live processing. Expected turnover, average ticket, MCC, countries, channels, settlement account, beneficial owners and sub-merchant model should have clear sources and effective dates. Investigators need a defined route to obtain underlying sub-merchant information where the acquiring model requires it.

For e-money and prepaid products, the requirements should cover issuance or wallet creation, verification tier, load source, transferability, internal value movement, merchant use, international use and redemption. Product limits and legal definitions should be configured by the applicable entity and jurisdiction rather than treated as universal values.

Across all products, the design should specify entity-resolution keys, data lineage, reconciliation method, audit trail, control owner, case owner, retention requirement and expected behaviour when a critical feed is missing or late.

Acceptance criteria that prove an outcome

Good acceptance criteria describe observable behaviour. Examples include:

  • cash deposits made by the same customer across several branches within the configured aggregation window are combined into one review population rather than assessed independently;
  • a legitimate cash-intensive business with verified seasonal turnover is not automatically escalated solely because its transaction count is high;
  • a low-value card-testing sequence followed by a higher-risk transaction can be linked through the relevant card, device, merchant or timing evidence available to the institution;
  • a merchant whose approved profile is updated through the formal review process is evaluated against the new effective profile without losing historical versions;
  • wallet-to-wallet movement remains visible to the issuer's monitoring process even when no external bank transfer occurs between the internal legs;
  • a corporate prepaid programme and a consumer gift-card programme can use different baselines without changing the underlying evidence and audit standards.

Weak acceptance criteria say only that “cash is monitored”, “cards are screened” or “wallets generate alerts”. Those statements describe functionality without proving that the control understands the product or produces a defensible outcome.

Controlled scenario testing

Product-monitoring tests should be run with synthetic, masked or formally approved test data in controlled environments. Test cases should be designed so the expected answer is known in advance and can be compared with the system result. Where a production-like environment is needed, normal change, data-protection and operational-approval procedures should apply.

Positive tests should cover the behaviours the control is meant to detect: cash aggregation across branches, card-testing sequences, merchant profile mismatch, linked wallet activity or coordinated prepaid redemption. Negative tests should cover legitimate but superficially similar behaviour, such as a seasonal cash business, a genuine burst of card purchases, a merchant expansion that was formally approved, or a customer using an e-money product within its intended purpose.

Boundary tests should check configuration around time windows, limits, segment changes and effective dates. The objective is not to prove that every amount immediately above a number becomes suspicious; it is to prove that the rule applies the configured policy correctly and preserves the surrounding evidence.

Failure-mode tests should simulate missing files, duplicate events, late-arriving data, source-system outages, unmatched identifiers, timezone differences and third-party data gaps. The system should show the degraded state clearly and follow the agreed fallback process instead of silently treating incomplete data as a clean result.

Calibration exercises for reviewers

Analyst calibration should use approved historical cases, anonymised examples or purpose-built training scenarios whose expected reasoning has been agreed by the control owner. Exercises should include obvious risk, obvious legitimate behaviour and genuine boundary cases where the correct action depends on further evidence.

The review should score more than final disposition. It should test whether the analyst understood the product, used the available data, separated facts from hypotheses, identified uncertainty, considered customer impact and followed the correct jurisdictional process. A correct answer reached for the wrong reason is not a reliable control outcome.

Calibration results can support coaching and case-routing decisions, but they should not become a shortcut for assigning all difficult work permanently to a small number of specialists. The operating model should build sufficient product knowledge across the team while preserving escalation routes for genuinely complex cases.

End-to-end data testing

A product control should be tested from source event to case record. For each critical field, the team should be able to show where it originates, how it is transformed, which identifier connects it to the customer or product and what happens when the field is missing.

Cash populations can be reconciled against branch and ATM source totals. Card data can be reconciled against processor authorisation or settlement counts, depending on the control's scope. Merchant data can be reconciled with the acquiring platform and settlement system. Wallet transfers can be reconciled to the internal ledger rather than only to external bank movements. Prepaid programme activity should be reconciled using the authoritative programme or processor population.

The case platform should preserve the rule or model version, source timestamps, enrichment used, analyst actions and final disposition. Re-running the same test against the same rule version and source population should produce explainable results.

Testing cross-product cases

Where the institution assembles activity across products, testing should prove that the relationships are real. A synthetic scenario might show cash deposited into an account, the account funding a wallet and the wallet transferring to another related customer. The expected output should state which links are verified and which are analytical leads.

Negative cross-product tests are equally important. Shared addresses, devices or beneficiaries can occur legitimately in households, businesses and service-provider relationships. Entity resolution should therefore preserve match confidence and avoid converting a weak relationship into a confirmed fact merely because several systems contain similar data.

Evidence required for sign-off

A defensible sign-off pack should contain the risk statement, product scope, source-data inventory, lineage, configuration, scenario or model specification, positive and negative test results, failure-mode results, known limitations, operational procedure, case examples, ownership and approval history. It should also identify any jurisdiction-specific assumption so that later regulatory change can be traced to the affected control.

The final question is simple: can the institution explain why the control behaves differently for cash, cards, merchants, e-money and prepaid products, and can it prove that those differences are deliberate, tested and governed? If the answer is yes, the control is product-aware. If the answer is no, a collection of alerts may exist without a coherent financial-crime control.

Masterclass: a fictional merchant profile that stopped matching reality

This is a fictional training case designed to show how merchant acquiring, card data and account activity can come together in an investigation. It is not based on a named institution, enforcement action or published supervisory case, and the figures are illustrative only.

The starting profile

Northbridge Travel Services is a fictional small travel agency. At onboarding, the acquirer verifies the company, its beneficial owners, website and settlement account. The expected profile is straightforward: mainly online card-not-present bookings, seasonal peaks around holiday periods, moderate average ticket values and settlements into the company's operating account. The merchant category and website content are consistent with travel services.

For more than a year, the pattern broadly fits the profile. Processing volume varies with seasonality, refunds occur when trips are cancelled, and settlement funds are used for ordinary business expenses and payments to travel suppliers. Nothing in that pattern proves the merchant is low risk forever; it simply gives the acquirer a baseline against which later activity can be compared.

The change

Over six weeks, card volume rises sharply. Growth by itself is not suspicious, so the monitoring process asks whether the change is explainable. The first inconsistency is transaction shape: a much larger share of payments are round amounts and occur late at night. The second is geography: new cardholders and IP locations appear from countries not previously important to the business. The third is settlement behaviour: funds are transferred quickly to a small number of new overseas beneficiaries rather than to the travel suppliers that dominated the historical account pattern.

At the same time, the merchant's customer-facing website still looks like a travel business. That creates an important investigative question rather than a conclusion. The acquirer needs to establish whether the business has legitimately expanded, whether it has introduced a new service that was never disclosed, whether another party is processing through the merchant account, or whether the merchant profile is simply outdated.

Building the case

The investigator assembles evidence from several sources. KYB records show no notified change in business model. The acquiring platform shows the shift in ticket size, time of day, cardholder geography and refund behaviour. Settlement-account data shows the new overseas beneficiaries. Website review does not identify a clear commercial explanation for the processing change. Customer-service records show a small number of cardholder queries describing unfamiliar merchant descriptors.

None of those observations alone proves transaction laundering. Together they justify enhanced review because the live activity no longer aligns with the merchant that was underwritten.

The analyst requests updated business information through the approved merchant-review process. The merchant explains that it has begun providing payment services for several partner websites but cannot provide a clear list of the underlying businesses or contracts showing why their transactions should be processed through the travel merchant account. That answer increases concern because the acquiring relationship was approved for the travel agency's own business, not for undisclosed third-party processing.

Separate the decision paths

Several teams now have legitimate interests in the case. Merchant risk considers whether the activity breaches the acquiring agreement or scheme requirements. Fraud teams assess whether cardholders are being deceived or whether stolen credentials are involved. AML assesses whether the activity and movement of settlement funds create suspicion of laundering or another reportable financial crime. Credit or settlement-risk teams may consider reserve or exposure implications.

Those decisions should share evidence but should not be collapsed into a single label. A contractual restriction can be justified even if the AML reporting threshold is not met. An AML report may be appropriate even if chargebacks remain low. A fraud concern does not automatically establish money laundering. Each outcome needs its own authority and rationale.

The evidence-led outcome

In this fictional case, the merchant cannot substantiate the new third-party activity. The acquirer therefore decides, under its own contract and risk process, to stop the undisclosed processing and begins an exit review. The AML team separately evaluates the unexplained third-party processing, new overseas beneficiaries and movement of settlement funds under the reporting rules applicable to the institution's legal entity. The case record shows which facts supported the contractual decision and which facts supported the AML assessment.

The institution also reviews related merchants and payment-facilitator relationships, but it does not automatically treat them as suspicious merely because they share a service provider or director. Any linked case requires its own evidence.

What the BA and architect should learn

The case exposes several design requirements. Merchant onboarding data must remain accessible to monitoring so live behaviour can be compared with the approved profile. The data model needs merchant ID, MCC, expected turnover, ticket range, countries, channels, beneficial owners, settlement account and effective dates for profile changes. Transaction data needs time, amount, currency, card channel and merchant identifiers. Settlement data needs beneficiary and timing information. Case tooling needs to preserve the relationship between all of those records.

The most important requirement is change visibility. If the merchant legitimately expands into a new activity and the acquirer approves it, the expected profile must be versioned rather than silently overwritten. An investigator reviewing an older period needs to know what the institution understood about the merchant at that time.

Testing should include both sides of the decision. A suspicious scenario should show a sustained profile mismatch and unexplained third-party processing. A negative test should show a legitimate travel agency expanding after completing the required review, with the new expected profile preventing unnecessary alerts. A third test should simulate missing sub-merchant or settlement data and verify that the case records the limitation rather than fabricating certainty.

The practical lesson

Merchant acquiring risk is not solved by one MCC rule or one chargeback threshold. The control works when the institution can compare the merchant it approved with the merchant it is actually processing for, retrieve the data needed to explain the difference and route each resulting decision to the correct owner. The same principle applies across the wider chapter: understand the product mechanics, preserve the evidence and avoid turning a signal into a conclusion before the investigation has earned it.

Knowledge check and glossary

Use these questions to test whether the product mechanics are clear enough to apply in a real bank or payment institution. The answers focus on reasoning rather than memorising one jurisdiction's thresholds.

Why can a cash control fail even when every individual deposit is below an internal or legal threshold?

Because the risk may sit in the relationship between transactions. Deposits can be distributed across days, branches, ATMs or related people. A useful control therefore aggregates the activity and compares it with the customer profile before applying the legal and policy rules that govern the institution.

Does repeated cash activity automatically mean structuring?

No. Repetition is a signal that needs context. A legitimate cash-intensive business can make frequent deposits. The question is whether the pattern is plausible given expected turnover, business model, seasonality, related parties and subsequent use of funds, and whether the evidence suggests deliberate avoidance of a relevant control.

What makes low-value card testing useful to an investigator?

A single small authorisation may be unremarkable. Its value increases when it can be linked to later activity through the same card, device, merchant, channel or timing pattern. Sequence analysis can therefore reveal credential testing that transaction-by-transaction review would miss.

Why should a confirmed card-fraud event not automatically become an AML conclusion?

Fraud prevention and AML answer different questions. A victim may have been deceived, an account may be controlled by a recruited or coerced mule, or a merchant may be involved in fraud without the evidence yet establishing laundering. The fraud event can trigger an AML review, but the AML outcome requires its own assessment under applicable law and policy.

What is the central monitoring question in merchant acquiring?

Whether the merchant's live processing still makes sense for the business the acquirer approved. Useful evidence includes MCC, expected turnover, average ticket, channels, countries, beneficial ownership, website or business activity, settlement behaviour and any relevant sub-merchant structure.

Does an MCC mismatch prove transaction laundering?

No. It may reflect stale data, a genuine business change, an onboarding error or undisclosed activity. The mismatch is a reason to investigate, not a conclusion. The institution should establish what changed and whether the merchant can support the explanation.

Why can payment-facilitator or aggregator models create a data problem?

Because the acquirer may see a master relationship while meaningful risk sits at sub-merchant level. If the control cannot retrieve the underlying merchant, transaction and settlement data needed for investigation, it may have a structural visibility gap.

What makes e-money monitoring different from ordinary bank-account monitoring?

The issuer may see value loaded into the product, transferred internally between wallets and redeemed without every internal leg appearing in the banking system. Monitoring therefore needs product-specific information such as funding source, wallet relationships, verification tier, internal transfer graph, limits and redemption behaviour.

Are tiered e-money verification and low-value exemptions universal?

No. The legal treatment of e-money and simplified or lower-friction arrangements differs by jurisdiction. The control should store the applicable legal entity, product type, verification status and rule version instead of assuming one global threshold or definition.

Why should prepaid products be analysed at programme level as well as instrument level?

One card may look ordinary while a programme shows many instruments funded from related sources, issued in unusual volumes or redeemed through the same locations. Programme type also changes what normal looks like. A corporate payroll programme is not comparable with a consumer gift card.

What is the most important distinction when reviewing gift-card scam activity?

The customer buying the cards may be a victim rather than a willing participant. Fraud prevention, vulnerability handling and AML may need to exchange evidence, but the institution should not turn unusual customer behaviour into an automatic criminal label.

What does good entity resolution do in a cross-product investigation?

It connects relevant identifiers while preserving the strength and provenance of the link. A verified customer ID is not the same as a weak address similarity. Match confidence, source and effective dates should remain visible so that an analytical lead is not silently converted into a fact.

Why does data lineage matter for product monitoring?

Because the control can only be trusted if the institution knows which events it receives, how fields are transformed, which populations are omitted and how completeness is checked. A card control that lacks authorisation attempts or a wallet control that lacks internal transfers may appear operational while missing the behaviour it was designed to detect.

What should happen when a source feed is unavailable?

The agreed failure behaviour should activate. Depending on the product and control, that may mean delayed processing, degraded logic, an operational alert, temporary restriction or another documented fallback. The important point is that incomplete data should not silently produce a clean result.

What is a good negative test for a cash-monitoring scenario?

A legitimate cash-intensive customer whose transaction volume is high but whose business profile, seasonality and supporting activity explain the pattern. Negative tests prove that the control can recognise legitimate product use rather than merely generate alerts.

What is a good negative test for merchant monitoring?

A merchant that expands into a new activity after completing the institution's required review, with the approved profile versioned correctly. The test should show that the control uses the effective profile rather than repeatedly alerting on a change the institution has already understood and accepted.

How should cross-product cases be assembled?

Because evidence connects the activity: a common customer, owner, device, beneficiary, funding source, merchant or clearly linked sequence. Multiple alerts by themselves are not enough. The case should preserve the originating alert and the reason each relationship was considered meaningful.

What should a reviewer record when evidence is incomplete?

The limitation itself. A defensible case distinguishes observed facts, analytical hypotheses, unresolved questions and assumptions. Recording uncertainty is stronger than filling a data gap with an unsupported conclusion.

Glossary for delivery teams

Aggregation: combining transactions across a defined population, time window or relationship so the control can assess a pattern rather than only one event.

Structuring: organising transactions in a way intended to avoid a relevant reporting, recordkeeping or control requirement. Legal definitions and thresholds depend on jurisdiction.

Card testing: low-value or repeated authorisation attempts used to assess whether compromised payment credentials are valid before further exploitation.

Transaction laundering: processing transactions for undisclosed or prohibited business activity through a merchant relationship that appears to represent a different legitimate business. The term is often used in acquiring and payment-processing contexts; evidence is required before applying it to a specific merchant.

Merchant category code (MCC): a payment-network classification associated with a merchant's business activity. It is useful context but does not by itself prove what every transaction represents.

Expected merchant profile: the documented view of the merchant's business, including factors such as activity, turnover, ticket size, channels, countries and settlement pattern, used as a baseline for ongoing monitoring.

Sub-merchant: an underlying merchant served through an aggregator or payment-facilitator model. The exact contractual and regulatory treatment varies by model and jurisdiction.

E-money: electronically stored monetary value issued under the legal framework applicable to the product. Definitions and permitted features differ across jurisdictions.

Wallet-to-wallet transfer: value moving between users inside a wallet or e-money platform, which may not create an external bank-transfer record for every leg.

Prepaid access / prepaid instrument: value made available in advance for later payment or withdrawal. Regulatory definitions differ; US FinCEN's prepaid-access rules are one jurisdiction-specific example rather than a global definition.

Load source: the method and origin used to put value into a wallet or prepaid product, such as bank transfer, card, cash agent or third-party funding.

Redemption / cash-out: converting stored value into bank funds, cash or another usable form, depending on the product's features.

Programme-level monitoring: analysis across a portfolio or prepaid programme rather than only at individual instrument level, allowing shared funding, issuance or redemption patterns to be identified.

Entity resolution: linking records that may represent the same person, company, device, merchant or relationship while retaining match confidence and provenance.

Data lineage: the documented path from source event through transformations to the field used by a financial-crime control or investigation.

Control degradation: a defined operating state used when a normal dependency is unavailable. It should be designed and tested rather than improvised during an incident.

Profile versioning: retaining historical and current customer, merchant or product expectations with effective dates so investigators can reconstruct what the institution knew at the time of an event.

Cross-product assembly: bringing connected activity from several rails into one case because evidence links the events, while preserving the separate alerts and decisions that originated in each product domain.

References and further reading

The chapter uses global standards for the risk-based framework and jurisdiction-specific material only as clearly scoped examples. Product definitions, thresholds, reporting duties and control obligations must always be checked against the law and supervisory framework applicable to the institution's legal entity.