12.1 Common Payment Methods, Crypto, and High-Risk Transactions Such as Aggregation
Key Takeaways
The FedNow Service launched in July 2023, joining the RTP network (2017) and the UK Faster Payments Service (2008) as real-time payment rails.
Wire transfers carry originator and beneficiary information under Travel Rule requirements, while many card and batch payments carry only limited counterparty data.
Aggregation, where one account or merchant ID carries many underlying payers or payees, hides the real originators and beneficiaries from the bank and monitoring tools.
Crypto payments settle on public ledgers, are pseudonymous and are generally irreversible, so screening must happen before funds leave the platform.
CAFCA sub-topic 3.4 asks you to know the common payment transaction methods, including cryptocurrency and other high-risk transactions such as aggregation. Monitoring and screening only work if you understand how money moves on each rail. That means knowing how fast it is, whether it can be reversed, and what data comes with it.
The main rails
| Method | How it works | Speed and finality | Data that travels with it | Typical abuse |
|---|---|---|---|---|
| Card payments | Four-party model: cardholder, issuer, network, acquirer and merchant | Fast authorisation; settlement later; chargebacks possible | Merchant name, merchant category code, card data | Card testing, transaction laundering, stolen-card funding |
| Push-to-card payouts | Funds are sent to a debit card through network push services | Near real time | Limited | Rapid cash-out of fraud proceeds |
| ACH and other batch rails | US ACH under Nacha rules (Same Day ACH added in 2016); UK Bacs; SEPA credit transfers and direct debits | Same day to a few days; returns and reversals possible | Limited originator and beneficiary fields | Unauthorised debits, account takeover funding, mule pass-through |
| Wires | Fedwire Funds Service (real-time gross settlement), CHIPS; SWIFT messaging for cross-border correspondent payments | Same day; final | Rich: originator and beneficiary under Travel Rule requirements | Trade-based laundering, sanctions evasion through correspondents |
| Instant payments | RTP (2017) and FedNow (July 2023) in the US; Faster Payments (2008) in the UK; SEPA Instant (2017); Pix in Brazil (2020); UPI in India (2016) | Seconds, around the clock; final | ISO 20022 data is often richer than legacy batch formats | Authorised push payment scams; mule networks; rapid layering |
| Wallets and P2P | Transfers between accounts on the same platform, or across apps | Instant inside the platform | Platform-specific; the counterparty may be another app | Funnel accounts, multi-app hopping, scam payments |
| E-money and prepaid | Stored value issued against funds received; open-loop cards or closed-loop gift cards | Instant use | Often light at load | Anonymous or low-KYC loads, gift-card cash-out |
| Cash networks | Retail reload points, ATMs, agents | Instant credit | Little or no customer data at the till | Structuring and placement of street cash |
| Cheques and remote deposit capture | Image deposit with delayed clearing | Days; can be returned | Payer data on the item | Altered, counterfeit or duplicate cheques |
| Crypto | On-chain transfers of crypto-assets and stablecoins | Minutes; irreversible on-chain | Public addresses only; identity needs VASP data and Travel Rule messages | Ransomware, scam proceeds, sanctions evasion, mixers |
Why rail knowledge matters for monitoring
- Data richness drives detection. Monitoring can only use the fields it receives. A wire with full originator data allows counterparty screening. A batch credit with a vague description may not.
- Speed drives control design. On instant rails, screening and fraud checks must run before release (Chapter 10). Batch rails leave time to review.
- Finality drives loss. Funds that leave over final rails, such as instant payments, wires and crypto, are hard to recover. Reversible funding methods create return and chargeback risk (next section).
High-risk transactions: aggregation and nesting
Aggregation means one account, merchant ID or wallet carries the payments of many underlying parties. Common forms in FinTech:
- Payment aggregators and payment facilitators, where many sub-merchants process under one master merchant account.
- Collection or for-benefit-of accounts that pool customer funds before distribution.
- Virtual account numbers that route many end-customers' payments into one master account.
- Nested payment providers, where another PSP or MSB uses the FinTech's account to serve its own customers.
Why aggregation is high-risk:
- Originators and beneficiaries disappear. The bank sees "Aggregator Ltd" rather than the 3,000 people behind it.
- Monitoring loses context. A spike may be one bad sub-merchant hidden among good ones.
- Responsibility can blur unless contracts and data flows make clear who does CDD on whom.
Controls include full due diligence on each sub-merchant or end customer by the party responsible, transaction-level data (not net settlement files), sub-merchant-level monitoring, contractual bans on unapproved nesting, and periodic audits (Chapters 2 and 17).
Other high-risk transaction types
- Cross-border payouts to high-risk jurisdictions or through many intermediaries.
- Cash loading and ATM withdrawals that bracket electronic movement.
- Prepaid and gift cards bought in volume or with stolen credentials.
- Crypto on- and off-ramps, especially to unhosted wallets or to high-risk exchanges.
- Third-party funding, where a payment comes from an account in someone else's name.
Realistic exam scenario
A FinTech gives a corporate customer, which describes itself as a "travel booking platform", 500 virtual account numbers. Funds from thousands of payers arrive and are settled out daily to accounts in several countries. The bank partner sees only one account name. This is aggregation, and possibly nested payment services. The FinTech must confirm whether the customer is licensed to provide payment services. It must obtain sub-account-level data, apply CDD to the payers and payees as the contract requires, monitor at the virtual-account level, and get the bank's approval for the structure. Without these controls the structure could hide unlicensed money transmission.
Common exam traps
- Treating all "instant" payments as low-value retail. Instant rails carry large business payments too.
- Assuming crypto is untraceable. It is pseudonymous; analytics and VASP data can attribute flows (Chapter 13).
- Ignoring the hidden parties behind aggregated accounts.
Why does aggregation create elevated money laundering risk for a partner bank?
Aggregation is illegal under FATF standards for all non-bank payment firms
Aggregated accounts always settle in physical cash at the end of each day
One account or merchant ID carries many parties, hiding the real originators and beneficiaries
Aggregators cannot be screened against sanctions lists because they hold no customer names at all
Which rail generally carries the richest originator and beneficiary data for counterparty screening?
Closed-loop gift card redemptions
Wire transfers subject to Travel Rule requirements
Cash loads at a retail reload point
Remote deposit capture of a personal cheque from a new customer
A neobank lets customers receive instant payments and immediately send them onward over the same rail. Which control design follows from the rail's characteristics?
No monitoring is needed, because instant rails are only used for low-value payments
Monitoring can be suspended outside normal business hours to save cost
Batch review the next morning is sufficient for instant payments
Screen and score payments before release, because settlement is final in seconds
Sections you finish are checked off in the contents.