The wallet is where AML controls succeed or fail

Two FIAU decisions this year turned on deposits that were never added up and risk assessments that came too late. Hassan Naveed of Scalara Labs argues that the fix belongs in the wallet, before money moves, and sets out five controls a compliance officer can test.

Most operators describe their anti-money laundering controls in terms of policy: a risk-based approach, a customer risk assessment methodology, a threshold at which due diligence applies. Regulators in Malta have spent 2026 testing something narrower and harder. They want to know whether the control actually ran, at the moment it was supposed to, against the money that was actually moving.

Two publication notices from the Financial Intelligence Analysis Unit make the point better than any guidance note.

What the FIAU found

In March, the FIAU imposed an administrative penalty of €225,730 on Stanleybet Malta Limited, with a periodic penalty of €2,000 a day attached to one specific failing. The company offered its games through a network of physical betting shops run by independent traders. According to the notice, it applied due diligence when a customer deposited €2,000 or more at one go, or when the same customer reached that sum in several transactions with one shop on the same day. Spotting the second case depended on shop staff recognising customers by sight. A customer who visited different shops, or the same shop at different times, could pass the threshold without anyone noticing. The FIAU said the €2,000 threshold has to be calculated on lifetime deposits or over a 180-day rolling period, and that the company could not link a customer's activity across its network. The notice also records onboarding forms that listed "savings", "wages" or "dividends" as the expected source of funds, sometimes with fields left blank. The company appealed to the Court of Appeal in April, so the penalty is not yet final.

In September, the FIAU published a settlement with European Lotto and Betting Limited. An administrative penalty of €94,780 was reduced by 35% to €61,607 under the FIAU's settlement policy. The findings included customer risk assessments that came late after the relevant thresholds had been met, default low-risk ratings for a large group of customers that the evidence did not support, and account structures for which no assessment was carried out at all.

Different businesses, different years under review, the same lesson. In both cases, the policy existed. What failed was the connection between the policy and the money.

Why this is a wallet problem

In many casino stacks, compliance and payments are separate systems that talk to each other occasionally. A deposit clears in the wallet in milliseconds. The risk assessment, the threshold count and the source-of-funds request live somewhere else, updated by a batch job, a webhook or a person working through a queue. For most deposits, that gap is harmless. For the deposit that takes a player across a threshold, it is the whole problem: the money has moved before the system that should have stopped it has caught up.

The alternative is to make the wallet ask first. Before a deposit or withdrawal is accepted, the wallet reads the player's current compliance standing and applies the limits attached to it. If the cumulative total would cross a threshold, the next check is raised before the money moves, not after a nightly reconciliation finds it. The standing is held in the account itself, so a payment cannot clear against a status that changed an hour ago.

That design does not replace judgement. An MLRO still decides where thresholds sit, what counts as suspicious and whether to report. It removes the part of the job that relies on staff noticing a pattern by eye, which is the weakness the Stanleybet notice describes.

Five controls to test

If you run compliance for a Malta-licensed operator, or are choosing a platform, these are the questions I would put to it. Each one maps to a finding above.

1. Do thresholds count cumulative deposits per customer, over the period the regulator specifies? Lifetime or a rolling 180 days, linked across every brand, shop or channel the customer uses. A per-transaction or per-day rule does not meet the requirement the FIAU set out.

2. Is the check enforced at the point of payment? Ask what happens to a deposit that would take a player over a threshold while their verification is still open. If the answer is "it clears, and we follow up", the control is a report, not a gate.

3. Does a source-of-funds request end in a document and a decision? A dropdown that records "savings" is a label. The record should show what was requested, what came back, who reviewed it and what they decided.

4. Is the reviewer's reason stored, including the decision not to escalate? Inspectors ask why nothing happened as often as why something did. A decision to clear a player should carry its reason and its time, the same as a decision to escalate.

5. Can a compliance officer produce the record without engineering? One player, one period or one control, exported from the back office in a form someone outside the business can read. If every regulator question starts with a ticket to developers, the evidence will be late, and late evidence reads badly.

Where the record matters

The common thread is a single trail of what every player, staff member and system did, in order, with the actor and the reason attached. When deposits, tier changes, document requests and reviewer decisions all land in the same append-only record, the questions from both notices become retrieval rather than reconstruction: when did this customer cross €2,000 over 180 days, what check was raised, who cleared it and why.

That is the approach we took when building compliance and audit tooling into our platform: the wallet reads a five-tier compliance standing before money moves, thresholds count deposits over a rolling window, and decisions carry the reviewer's reason. But the five tests above apply to any platform, and to an in-house build. Malta's regulators have made clear which part of the stack they will examine. Operators should make sure it is the part that does the work.