There is a persistent architectural assumption in payment fraud infrastructure that is worth examining directly: the idea that you score a transaction for fraud, and then decide what to do with that score in a separate step. This model made sense when scoring took seconds. It does not make sense now.
Where the authorization window actually closes
In a typical card-not-present payment flow, the sequence runs roughly as follows: the customer submits payment details, the merchant's payment gateway validates the card token, the acquiring bank sends an authorization request to the card network, and the issuing bank responds with an approval or decline. That entire sequence, from gateway submission to authorization decision, completes in 1.5 to 3 seconds depending on network conditions.
Fraud scoring systems that operate outside this window -- running asynchronously after authorization -- are producing scores that arrive too late to affect the authorization decision. The transaction is already approved or declined before the fraud model has run. What you have is not fraud prevention; it is fraud documentation.
The practical consequence is that post-authorization fraud systems can only influence what happens after the fact: chargeback disputes, account suspension, refund holds. Those are real levers, but they are expensive levers. By the time you are disputing a chargeback, you have already absorbed the cost of the transaction, the fulfillment, the customer service inquiry, and the processing fee. Prevention operates at a fraction of that cost.
The pre-authorization scoring constraint
To score a transaction before authorization completes, your scoring system must return a result inside the authorization window. In practice, that means the API call to your fraud scoring service must complete and return before the gateway sends its own authorization request, or at minimum before it processes the response.
At Riskgrove, we built the scoring architecture around this constraint from the start. Our target is a p50 latency under 40 milliseconds, with p99 under 90 milliseconds. Those numbers are not arbitrary -- they come from measuring the time budget a payment gateway integration actually has before it needs to pass the authorization result to the merchant's checkout flow.
The engineering challenge is significant. Running gradient-boosting models over 200+ transaction signals in under 40 milliseconds requires careful attention to feature computation, model serving infrastructure, and request routing. A naive implementation that serializes feature lookups will blow the latency budget in the feature retrieval phase alone, before the model has even run.
What signals are actually available before authorization
A common objection to pre-authorization scoring is that you don't have much data to work with -- the transaction hasn't happened yet, so how can you score it? This objection misunderstands where fraud signal comes from.
The most predictive fraud signals are behavioral and contextual, not transactional. They are about what has happened in the recent past, what this entity has done before, and how the current transaction fits into a pattern. All of these signals are available before authorization completes:
- Device fingerprint history: How many cards has this device identifier tested in the past 24 hours? Have previous attempts on this device resulted in declines?
- User session behavior: How long since this account last logged in? Did the login use the same device? Were there password reset attempts recently?
- Card velocity across entities: Has this card number appeared on other device fingerprints recently? Has this card been used on merchants with different MCC codes in a short window?
- IP and network context: Is this request coming from a datacenter IP or residential? Does the IP geolocation match the billing address?
- Merchant-specific baseline: Is this transaction amount unusual for this merchant? Is the MCC consistent with what the card has been used for before?
These signals are all computed from historical state that exists in your systems right now. Gathering them quickly -- within the latency budget -- is the engineering problem to solve. Waiting for authorization to complete does not give you better signals; it just moves the scoring to a point where the score cannot change anything.
The post-authorization fraud model's actual use case
To be clear: post-authorization fraud analysis has a legitimate and important role. It is the right tool for dispute investigation, for building long-term fraud pattern reports, for training the next version of your fraud model, and for operating your chargeback dispute workflow.
Post-authorization analysis is excellent at explaining why a transaction turned out to be fraudulent after the fact. Pre-authorization scoring is what prevents the fraudulent transaction from completing in the first place. These are complementary tools, not alternatives. A mature fraud stack uses both.
What we built at Riskgrove specifically addresses the pre-authorization gap. The assumption in our API design is that you call us before your authorization request completes, you get a risk score back in time to act on it, and you make a decision: approve, challenge, or decline. The score you receive reflects what we know about this transaction entity, this device, and this behavioral pattern right now, not 30 seconds from now.
Why latency matters more than model accuracy at the margin
Here is a counterintuitive point that comes up regularly: improving fraud model accuracy from 92% to 94% is often less valuable than reducing scoring latency from 200ms to 40ms. The reason is that a highly accurate model running outside the authorization window produces zero prevented transactions. A moderately accurate model running inside the window prevents thousands of fraudulent transactions per month.
This is not an argument against model accuracy -- you want both. It is an argument for being precise about the constraint that actually governs whether your fraud scoring has any impact on authorization decisions. Latency is the binding constraint. Everything else is optimization within that constraint.
For risk teams evaluating fraud scoring APIs, the first question to ask any vendor is not "what is your precision/recall?" It is: "what is your p50 and p99 latency, measured from API receipt to response?" If the answer is in hundreds of milliseconds, or if they decline to share the number, the model accuracy question becomes less relevant -- you may be building a post-authorization system without realizing it.
The authorization window problem is architectural. Solving it requires a scoring system designed around latency as a first-class constraint, not bolted on as an optimization afterthought.