The approved document already requires this behavior, or leaves room the code fills with the stricter reading. Fixing the code is a bug fix, not a methodology change: Compliance gets a conformance memo for acknowledgment, not an approval request. Quotes come from the Notion methodology hub — check them against the regulator-facing sheet (Met.GRP/FC/003) before circulating further.
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: assets from expired and abandoned attempts feed both asset factors forever.
Add the status filter the document already requires. Scope: the released-only rule covers assets and wallets (wallets already comply) — the document counts payment methods "regardless of their current state" and integrators "ever used", so those stay untouched here. code · query filter
The methodology defines Pay Country as the method "attached to a newest transaction". The code takes the most recently stored or used instrument — deleted ones included — so 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 counting rule covers "all payment & payout methods", and its example: "a user uses 4 different cards — this equals 1 payment method". On-ramp follows it; off-ramp counts every distinct instrument, so 3 SEPA payouts to 3 accounts = 3 methods.
Apply the documented counting rule to the payout side: count by type. The document's worked examples are card-side — the memo should say the payout reading is by direct analogy from the rule sentence that names payout methods. code · counting rule
The document: "Payment method used for both payin & payout is considered a single payment method." The code sums the on-ramp count and the off-ramp count with no overlap check — the same rail counts twice.
Dedupe across directions before summing, as written. code · one sum
USDC on two chains counts as two assets toward the usage factor. The methodology says "different cryptoasset tokens purchased/sold" and never defines the granularity — the chain qualifier is our storage key, not a statement in the document.
Resolve the ambiguity at token level: dedupe by symbol. One of the bucket's two interpretation calls — the memo should name them as such. code · dedupe key
Country equality in the mismatch factor also compares the risk rating. The country lookups share a 3-minute cache, so within one calculation they normally agree — but a rating edit that crosses a cache refresh mid-calculation makes the same country unequal to itself: a phantom mismatch at the model's heaviest weight.
Compare countries by country code. One equals method. Rare, but silent and unauditable when it fires — and the spec defines the factor purely as country ≠ country. code · one method
The provider query behind the KYT factor takes the single highest-level alert ever — no status filter, no window — so an alert FinCrime reviewed and dismissed as a false positive drives the factor for life. Meanwhile our own post-monitoring importer explicitly skips dismissed alerts.
Exclude dismissed alerts in the CRR query too — one system, one meaning of dismissed. The document says "any KYT hits"; a hit that did not stand review is not a hit. The bucket's second interpretation call. code · provider query
Changes to the written methodology, but with no defensible AML reason to keep the current behavior. One page each, shipped together as a model-hygiene package with a before/after number per item.
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. Falls away if item 16 lands. methodology · definition
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. Falls away if item 16 lands. methodology · definition
The methodology maps a KYT alert the vendor rated LOW to a MEDIUM score — only "no risk" scores low. The model is stricter than its own risk vendor, with no stated reason.
Map provider-LOW to a low score. A one-line change, but the mapping is written in the document, so it takes the one-pager. methodology · mapping
A self-declared unhosted wallet scores HIGH — the same as a completely unknown wallet — while a discovered unhosted wallet scores MEDIUM. Disclosure scores worse than being caught.
Declared-unhosted becomes MEDIUM; unknown stays HIGH. AMLD5 encourages declaration; the model should not tax it. One switch statement. methodology · mapping
No assets, no wallets, no integrator each score 50 × weight — 13.75 free points on every first transaction, before the user has done anything. Absence of data is not evidence of risk.
Set the defaults to zero. V4 already zeroed the country defaults; finish the job. config · defaults
CRR recomputes only when the user transacts. A user stuck at HIGH cannot improve without transacting through the very wall that blocks them.
Trigger recalculation on improvement events (method removed, rating-table change) and a periodic sweep. The formula does not change, only when it runs — if the methodology mandates periodic review, this is bucket 1 conformance. code · trigger
Changes that need a domain argument, a policy decision, or a new factor. Eight items, but three papers: they cluster into three arguments.
Paper A · domain purity — fraud signals leave the AML instrument
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. Interim fallback: V5's halved weight plus EEA grouping. 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 — the one change that is a non-action. 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
Paper B · positive signals — the model's only way to reward tenure
Items 14–18 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
Paper C · decay and materiality — the model must be able to forget
One KYT alert, one risky integrator, one bad wallet — the worst record ever holds its factor forever. Velocity is the only input in the whole model that decays.
Count histories over a rolling window. The model must forget on the same schedule our retention and review policies do — one window length to approve per input. methodology · windows
One tiny purchase of a HIGH-rated asset holds the asset-risk factor at HIGH forever. Exposure without materiality.
A value threshold before an asset counts toward risk appetite. Materiality thresholds are standard compliance practice — expect the "any exposure is exposure" pushback, hence the paper. methodology · threshold