The analyst's side

Give a language model a case file and it will summarize it, put the timeline in order, draft the SAR narrative, and point at the other accounts that share a device with the one you are looking at. That is real leverage. An analyst who spends less time typing up what happened has more time to decide what it means. I use it that way, and I would tell anyone working a queue to do the same.

The decision's side

Now put the same model in front of an auditor. The customer has disputed a closure. The regulator wants to know why this account was frozen and that one was not. "The model scored it high" is not an answer. Neither is a probability. The person who owns the decision has to be able to say which facts drove it, in what order, and why those facts justify the action taken. They may have to say it under oath.

A model cannot testify. It cannot defend a dispute. It cannot walk an examiner through its reasoning in terms the examiner is required to accept. Whoever signed off on the decision can, but only if the system underneath them explains itself.

What explaining itself looks like

Reason codes, mostly. Every decision carries the specific signals that fired, in plain language, with the evidence attached. "Bank fingerprint shared with previously closed accounts." "Document MRZ checksum failed." "Device seen on multiple identities inside a day." The list is finite, it is versioned, and a person can read it without a data science degree.

That constraint is why KYC Sentinel Lab returns 36-plus explainable reason codes instead of a score. A score tells you what the system thought. A reason code tells you what the system saw, which is the only thing an auditor, a dispute analyst, or a court will accept. Building the codes is more work than training the classifier. It is also the difference between a decision you can defend and a decision you hope nobody asks about.

Use AI to make the humans faster. Keep a human on the decision. And build the system so that when someone asks why, the answer is already written down.

It is also a way of paying, every month, for a decision you never made.

What review is for

Manual review exists for the cases where judgment matters: the ambiguous identity, the customer who looks like a mule but might be a grandparent, the first instance of a pattern nobody has named yet. That work is valuable, and it is why fraud teams need experienced people.

Most of what lands in a review queue is not that. It is the same handful of situations arriving over and over, decided the same way every time, by someone whose expertise is being spent on typing "approve." When I pulled the decision history on a deposit queue I once owned, most outcomes were predictable from a handful of signals. The analysts already knew that. Nobody had written it down.

Automate the 80%

The split I aim for is rough but useful. Roughly 80% of a queue follows rules people already apply in their heads. Transcribe those rules into code, add the guardrails Compliance needs, and let the system decide. The remaining 20% is where the judgment lives. Route it to people, and send the reason along with it so the analyst starts from the anomaly instead of from a blank screen.

That is not a smaller team. It is a different team: fewer people processing, more people investigating, and a queue that stays short even when volume does not. The deposit-limit work I wrote about followed exactly that shape.

What hiring your way out costs

Reviewers scale linearly with volume. Fraud does not care about your hiring plan. A team built on manual review has a detection ceiling equal to its headcount, and its best people spend their days on the cases that least need them. The budget line grows, the backlog barely moves, and the pattern nobody has noticed yet keeps running because everyone is busy.

Automate the decisions you can explain. Put people on the ones you cannot. Review is a tool, and a tool is not a strategy.

That is the problem with dashboards. They answer yesterday's question. Fraud is whatever the current question is.

Where the rings actually show up

Every ring I have found showed up first in a query nobody had asked for. Not in a chart. Accounts that shared a bank fingerprint but nothing else. Deposits that landed minutes apart across identities that were supposed to be strangers. A refund pattern that only looked wrong when you grouped by device instead of by customer. None of those had a tile, because nobody knew to build one until after the query ran.

A dashboard is a frozen query with a nice frame. The moment the pattern shifts, the frame is pointing at the wrong thing, and the person who can re-aim it is the person who can write SQL.

The budget decision and the hiring decision

Buying a dashboard tool is a budget decision. You sign, you get charts, and the vendor's roadmap decides what you are allowed to ask. Hiring someone who writes queries is a hiring decision. It is slower, it needs a manager who can tell good SQL from bad, and the payoff is a team that can ask a new question on a Tuesday afternoon without filing a ticket.

Most teams pick the budget decision because it is easier to approve. Then they wonder why detection plateaus while the vendor bill grows.

What I would actually do

Keep the dashboards. They are good at the boring, repeated questions, and boring repeated questions matter. Then make sure at least one person on the team, ideally more than one, treats the warehouse as their primary tool, and give them the time to go looking. Queue metrics improve when you close cases. Detection improves when you find the thing the queue does not know about yet.

The analyst who can write a query is not a luxury on a fraud team. They are the part of the team that can see.

At Binance.US, ours was deposit limit increases. A customer asked for a higher limit, the request went to a person, the person read the account history and said yes or no. The queue grew faster than the team did, funding got delayed, and two analysts looking at the same account could land on different answers. Customers experienced all of that as "the exchange is slow."

Reading the decisions we had already made

Before automating anything I pulled the history of approvals and denials and asked one question: what were we actually checking? The honest answer was a short list. Account age. Verification tier. Deposit and withdrawal history. Whether anything had ever flagged. Most approvals were predictable from that handful of signals. The judgment calls were real, but they were a minority of the queue.

That is the shape you want to find. When most decisions follow rules people already apply in their heads, the automation is not a model. It is a transcription. Stripped down, the logic looked like this:

def decide(request: LimitRequest) -> Decision:
    account = request.account

    if account.open_flags or account.kyc_tier < REQUIRED_TIER:
        return Decision.review(reason="guardrail")

    within_tier = request.amount <= ceiling_for(account.kyc_tier)
    clean = account.clean_days >= CLEAN_HISTORY_DAYS
    if within_tier and clean:
        return Decision.approve(reason="within tier, clean history")

    return Decision.review(reason="outside criteria")

Two things mattered more than the code. Compliance helped write the guardrails, so the automation never approved something a person was not allowed to approve. And anything that fell outside the criteria went to a human with the reason attached, so the analyst started from "this tripped the withdrawal-velocity check" instead of from zero. We watched the automated decisions with the same quality checks we ran on people.

What changed

Product, Engineering, and Compliance each owned a piece, which is why it took months rather than days. Once it was live the queue emptied fast, and the analysts spent their time on the cases that needed them.

Results  backlog down 67% in three weeks · manual review time down 50% · customer satisfaction up 23% · funding per customer up 31%

I have automated more interesting things since. This is still the one I point to, because the hard part was not technical. It was getting a room of people to agree on what a yes looks like.

At Binance.US, a handful of new accounts landed in my queue with the same shape: fresh identity, bank account linked through Plaid, verification passed, small deposits, then withdrawals to the same few places. Any single account was defensible. The rules engine agreed, because every rule we had scored one account at a time. Nothing scored the group.

What the rules could not see

Synthetic identities do not share identity fields. That is what makes them synthetic. The names, dates of birth, and addresses were all different. The ring was based in Nevada, but the addresses on file were not what gave it away. What the accounts shared was infrastructure: the same bank account fingerprints coming back from verification, the same devices, deposits landing minutes apart, withdrawals fanning out to the same destinations.

So I stopped looking at accounts and started looking at edges. In Snowflake, that is a self-join on the things people reuse when they run a ring at scale. Simplified:

with links as (
  select a.account_id, b.account_id as linked_id, 'bank' as reason
  from accounts a
  join accounts b
    on a.bank_fingerprint = b.bank_fingerprint
   and a.account_id < b.account_id
  union all
  select s.account_id, t.account_id, 'device'
  from sessions s
  join sessions t
    on s.device_id = t.device_id
   and s.account_id < t.account_id
)
select account_id, count(distinct linked_id) as degree
from links
group by account_id
order by degree desc;

The first pass took about 48 hours and turned a handful of suspicious accounts into a network of more than 200. The exposure across it came to $3M+. Run the same query the next morning and the network had grown, which told me the ring was still onboarding.

Closing the gap

The uncomfortable finding was not the ring. It was that we were treating a passed bank verification as proof of a person. It is proof of a bank account. I wrote up the gap, took it to the vendor and to Risk Engineering, and we turned the linkage logic into detection rules that fired on shared infrastructure rather than on any one account's behavior. Legal and Compliance handled the closures. I turned the queries into a playbook so the next analyst would not start from a blank editor.

Results  $3M+ exposure identified · 200+ accounts closed · first map in 48 hours · 15% fewer false positives from the new rules

The lesson I kept: rules see one account at a time. Rings do not operate one account at a time. If your detection cannot join, it cannot see the thing that matters.