Coinbase Upgrades Payment Fraud Prevention with a 9-Billion-Parameter Model: Online Fraudulent Transactions Drop 30%

Figure 1 | Coinbase engineering team published a series of research on anti-fraud Agents

A credit card purchase of crypto assets appears, on the surface, to involve only an amount, a device, and a payment result. Fraudsters, however, often split their attacks into multiple attempts: first testing the card with a small transaction, then changing devices, addresses, or payment instruments, and finally completing a larger purchase. Looking at any single transaction in isolation, the risk signals may be weak; only when the recent actions are examined together does a pattern emerge.

From October 6 to 8, 2026, Coinbase published three consecutive engineering articles describing how it built an anti-fraud Agent for its Onramp business. Coinbase first connected a large language model after its existing machine learning models and rules engine, using it to read transaction sequences; it then built domain-specific test sets to compare different versions of closed-source models; and finally used its own fraud data to post-train a 9-billion-parameter open-weight model. According to the company's disclosed online experiments, after adding the Agent, the number of fraudulent transactions dropped by 30% and the fraud amount dropped by 22%. The post-trained model achieved a higher F1 score on its internal benchmark, with lower end-to-end latency.

These figures come from Coinbase's own experiments, and the complete dataset cannot currently be reproduced externally. Nevertheless, this set of practices provides a very concrete enterprise AI sample: in narrow tasks like payment risk control, model recency and scale may not rank first. What truly affects outcomes is whether an enterprise has reliable outcome data, whether it can build test sets that approximate real business scenarios, and how model outputs enter the existing decision system.

1. Traditional models filter first, the Agent reads the transaction process

Figure 2 | The processing path of a transaction entering the anti-fraud Agent

Coinbase Onramp allows users to purchase crypto assets within partner apps, and some scenarios permit guest checkout. Guests have no long-term account history, so the information available to the platform mainly comes from the current payment and recent transaction behavior. The existing machine learning models are good at quickly processing single-transaction features, while the rules engine intercepts clear anomaly conditions, such as repeated failures, sudden device changes, or inconsistent payment information.

The difficulty emerges in sequential actions. A certain purchase may have an ordinary amount and device, but when placed back into the transaction sequence of the past few minutes, it may immediately follow multiple small test transactions, card changes, and address changes. Coinbase organizes recent transactions chronologically into context and then hands them to the large model for risk assessment. The model outputs a brief risk classification, and downstream programs use this classification to decide whether to approve, reject, or route to manual review.

This structure preserves the speed of the traditional risk control system. The vast majority of transactions are first processed by machine learning models and rules, and the Agent only joins when more context is needed. Its task is also strictly limited: read the already-organized transaction information, identify relationships in the sequence, and return conclusions in a specified format. The final action is still executed by the policy layer in the system.

This division of labor explains why Coinbase calls it a risk Agent. It does not investigate customers on its own, nor does it freely call all internal systems. The platform constrains its data scope, question format, and permissible answers, so the model can focus its attention on the narrow question of "whether these transactions are anomalous when connected together."

2. Model upgrades may silently change the risk scale

After the first phase went live, the next problem Coinbase encountered was model selection. General benchmarks often tell enterprises which model is stronger overall, but payment risk control cares about more specific metrics: how much fraudulent activity can be stopped, how many legitimate users are mistakenly affected, whether high-value fraud is identified, and how long each decision takes.

Coinbase built test sets using its own historical data to compare multiple Opus, Sonnet, and GPT versions. The company disclosed that some newer models, despite improved precision, actually showed lower recall, F1 scores, and amount-weighted recall. Precision indicates how many transactions the model flags as fraud are actually fraudulent; recall indicates how many of all fraudulent transactions are found. If a risk control system pursues only higher precision, it may reduce false positives while missing more real losses.

The F1 score is used to observe precision and recall together. Simply put, it helps teams determine whether a model is only performing well on one metric. Coinbase also added amount-weighted recall, because missing a single large fraud typically causes far greater loss than missing a small transaction.

Model upgrades thus become a risk policy change. Even if prompts, interfaces, and approval rules remain unchanged, a new model may reinterpret suspicious behavior differently, moving transactions that were previously approved into rejection, or letting through fraud that the old version could identify. Before switching models in production, enterprises need to re-validate using their own test sets and cannot directly use vendor-published overall rankings as the basis for deployment.

3. Why a 9-billion-parameter model can outperform larger closed-source models

Figure 3 | Three results of the small model shown on Coinbase's internal benchmark

Coinbase then chose Qwen3.5-9B for post-training. This model has only 9 billion parameters and can be trained and deployed on a single NVIDIA RTX PRO 6000 96GB GPU. The team converted historical transaction outcomes into verifiable rewards: the model is rewarded when its judgment matches known fraud outcomes and penalized when it is wrong, and the model is then adjusted through reinforcement learning.

The RLVR used here stands for "Reinforcement Learning with Verifiable Rewards." Payment transactions ultimately produce outcomes such as chargebacks, confirmed fraud, or normal completion, and these outcomes can serve as relatively clear training signals. The model does not need another large model to evaluate whether an answer is "like a good judgment"; it faces business outcomes that have already occurred.

The number of fraud samples is usually far smaller than that of normal transactions. If the reward function only looks at overall accuracy, a model that classifies almost all transactions as normal could still produce a seemingly good number. Coinbase therefore balanced the contribution of fraud and normal samples and used LoRA to train a small number of additional parameters, enabling the model to learn fraud patterns in the Onramp business.

The company disclosed that, on internal benchmarks, the post-trained model achieved precision 7.5 percentage points higher than Opus 4.5, recall 12 percentage points higher, F1 9.6 percentage points higher, and amount-weighted recall 35.4 percentage points higher. End-to-end latency for online inference dropped by 55%, and training cost was under $100. These results target a narrow classification task and show that domain adaptation can train a smaller model into a more suitable production tool.

4. The model only provides a risk conclusion, the system decides how to handle it

Coinbase did not let the model directly control transactions. The Agent harness is responsible for organizing transaction information into input and then translating the risk classification returned by the model into actions the system can execute. During training, the model can be asked to explain its reasoning; for online payments, only a compact risk result is needed to reduce latency and format errors.

This intermediate layer is very important. It specifies which fields the model can see, how missing values are handled, which categories are returned, how long before a timeout is considered a failure, and which old rules to fall back on when the model does not respond. Model versions can be changed, while the permission boundaries of the payment system continue to be controlled by the program.

Manual review is still retained. High-risk transactions, transactions where the model conflicts with traditional rules, or edge cases involving larger amounts can enter a manual queue. The review results then become new data, helping the team discover fraud tactics not covered by the test set. Models, rules, and human judgment thus form a continuously updated closed loop.

This closed loop also brings new governance requirements. Enterprises need to record model versions, input fields, risk conclusions, and final dispositions in order to reconstruct the decision at the time during complaints, chargebacks, or regulatory examinations. When training data includes payment behavior and device information, data access, retention periods, and subsequent training use must also be controlled.

5. The way enterprises choose models is changing

Figure 4 | Enterprise model procurement shifts from general leaderboards to domain evaluation

Large model procurement used to revolve around general capabilities, context length, and vendor brand. The Coinbase case brings the selection criteria back to specific business concerns: whether test data approximates real traffic, how error costs are distributed, how much latency the system can tolerate, and whether the model can run stably in existing infrastructure.

For financial institutions, this means model evaluation must be designed alongside risk policy. Anti-fraud, anti-money laundering, credit review, and anomalous transaction detection all involve sample imbalance, and a single accuracy metric can easily mask problems. Teams need to observe recall, false positive rate, monetary loss, and customer conversion simultaneously before setting approval thresholds.

Open-weight models thus gain a new position. Enterprises can train and deploy them in their own environments, retaining control over model weights, serving methods, and version cadence. The cost is that enterprises must bear responsibility for training security, model evaluation, infrastructure, and ongoing maintenance. Having data is not enough; the data must also map to clear business outcomes.

The Coinbase practice ultimately lands on a simple judgment: payment risk control does not need a model that can answer every question. It needs a model that is familiar with this type of transaction, responds fast enough, has measurable errors, and always stays within established permissions. Once enterprise AI enters production systems, the most valuable capabilities often come from this kind of narrow and stable adaptation.

This article is intended solely for legal, policy, and industry research exchange, aiming to provide objective analysis of digital finance, stablecoins, digital assets, and related regulatory developments. It does not constitute investment advice, legal advice, tax advice, or any other professional advice in any form, nor does it constitute a recommendation, promotion, or solicitation for any financial product, digital asset, or commercial project. The regulatory rules, market data, and institutional information mentioned in the article are mainly sourced from public materials and may be adjusted due to changes in laws and regulations, regulatory policies, market conditions, and project progress. Readers should make independent judgments based on the latest public information and comply with the laws and regulations applicable in their country or region. The author and publishing platform assume no responsibility for any investment, trading, or other business decisions made in reliance on the content of this article.