The methodology says asset usage and asset risk consider "only assets from released (successful) transactions, both on-ramp & off-ramp". The code obeys on-ramp and ignores it off-ramp: expired and abandoned attempts feed the factors forever.
Add the status filter the document already requires. code · query filters
The methodology defines Pay Country as the method "attached to a newest transaction". The code takes the newest stored instrument — a foreign card added while traveling shifts the country before it is ever used. A dead timestamp on the off-ramp side additionally makes on-ramp always win the newest-wins comparison.
Read the country from the payment method of the transaction under evaluation, as written. code · selector
The methodology's own example: "a user uses 4 different cards — this equals 1 payment method". On-ramp follows it; off-ramp counts every distinct IBAN, so 3 SEPA payouts = 3 methods.
Apply the documented counting rule to the payout side. code · counting rule
USDC on two chains counts as two assets toward the usage factor. The methodology speaks of assets; the chain is an implementation detail of ours, not a property of the user's behavior.
Dedupe by token symbol. code · dedupe key
The factor "considers any KYT hits" — and the code counts alerts that FinOps reviewed and rejected as false positives, forever (no status filter, no window).
A hit that did not stand review is not a hit. Filter alert status in the provider query. code · provider query
Country comparison in the mismatch factor also compares the risk rating, so a rating edit mid-calculation makes the same country unequal to itself — a phantom mismatch at the model's heaviest weight.
Compare countries by country. One equals method. code · one method
Its risk theory is a stolen card or a taken-over account — fraud, policed by the fraud stack. For ML/TF the firm's own audit (Rec 6) found weak-to-negative correlation with financial crime. It carries the heaviest weight in the model: 20%.
Execute the audit finding: drop the factor. Fraud keeps its own controls; the AML methodology stops paying 20% for a signal the audit rejected. audit Rec 6
A raw count of transactions per 24h is a card-testing and account-takeover control — fraud again. ML velocity means value structuring, and that is what transaction monitoring and KYT exist for. The implementation waiting in V5 is also nonconformant: it counts on-ramp only and partial statuses.
Leave the weight at zero. Remove rather than repair. V5 · before promotion
Counting how many payin methods a user tried is a card-testing signal. The ML-relevant half is the other side: how many payout destinations the funds fan out to — that is layering.
Keep the payout-destination count, drop the payin-method count. factor split
"4+ accounts in a group → HIGH", hard-coded, inside the wallet-risk factor. Multi-accounting is an abuse signal unless the accounts are linked by transactions — and the rule does not require that.
Move it to the antifraud check that already exists in the same execution graph, or redefine it on transactional links. fraud stack (Af)
Counting distinct assets measures diversification, not ML/TF risk — the audit said so itself (Rec 9). Neither a fraud signal nor a compliance one.
Drop it, as the audit recommends. audit Rec 9
Items 07–11 free roughly 30 points of weight. Today the model has no positive signal at all: tenure can only hurt.
Fund a clean-history factor — months without a KYT alert, a screening hit, or a SAR, scoring down — and strengthen the genuinely ML/TF factors. FATF's risk-based approach explicitly permits lower risk on documented absence of AML signals. Weights still total 100. methodology version
The methodology counts them separately by its own example: "2 cards and Apple Pay — this equals 2 payment methods". But Apple Pay and Google Pay tokenize the same cards; it is one funding rail, and using it should not read as broader payment-method exposure.
Amend the definition: card-wallet types collapse into CARD for the count. Relevant while the payin counter survives item 09 — if 09 lands, this falls away with it. methodology · definition
The methodology counts methods "regardless of their current state (i.e. also count payment method added and then deleted)" — by design. So a user who replaces cards over the years accumulates exposure that no longer exists.
Amend the definition: a removed instrument is not an ongoing exposure; count active methods. Same dependency on item 09 as above. methodology · definition