mirror of
https://github.com/luxfi/aml.git
synced 2026-09-24 00:25:20 +00:00
zeekayandHanzo Dev
9f098d396c
Ingest defaulted the customer's name from its identifier, so an opaque database key was screened against the designation lists. Measured against the live lists, "cust-1" scored 0.902 against "BRANCH 1 OF THE SHIRAZ REVOLUTIONARY COU" — above the 0.85 reporting threshold — and an ordinary $100 payment came back blocked. A handle cannot produce a true positive against a list of people's names, so every match it yields is false, and this one was the most expensive kind of false: the rule's action is block, so the engine declined a legitimate payment and named a sanctions hit as the reason. The customer now comes from the caller, who is the only party that knows it. With no name supplied the customer-screening rule's own guard holds and the rule does not fire, which is the honest outcome — a customer whose name this service has never been given has not been screened, and the way to screen them is to send the name rather than to invent one from a key. The catalog already publishes this as a gap. Measured end to end on a benign $100 payment, against 31,338 loaded designations: six alerts at a saturated score before this arc, then two, then blocked, and now allow / score 0 / no alerts. A designated party still matches — "Vladimir Putin" returns 28 hits, exact on OFAC, EU and OFSI. Also here: a second defect this exposed and did not fix. The matcher scoring a six-character single token at 0.902 against a six-word organisation name is wrong on its own terms, whatever is fed to it. The single-token asymmetry does not hold on this path. Left as a named finding rather than a hurried threshold change, because raising the threshold to hide it would suppress genuine transliterations, which score lower than this false positive did. Co-authored-by: Hanzo Dev <[email protected]>