Dynamic Routing Engine

TL;DR

The EVX Technologies Ltd payment orchestration platform lifted debit card authorisation rates from 78% to 91% in production. The programme was a zero-to-one infrastructure build targeting clean high-risk merchants – a segment the mainstream acquiring industry rejects through blunt MCC-level risk categorisation. What made it hard was designing a five-model probabilistic routing architecture and proving its commercial case before any acquirer would formally underwrite the merchant book.

CONTEXT

EVX Technologies Ltd built a payment orchestration layer for merchants in high-risk verticals – online gambling, sports betting, nutraceuticals, and subscription commerce – that generate legitimate card volume but are routinely declined or de-banked by tier-1 payment gateways and acquiring banks. The structural failure is consistent: mainstream payment gateways apply static MCC-level risk categorisation, assign merchants a single processing route, and provide no fallback when that acquirer’s risk appetite shifts.

The commercial gap was an orchestration layer this segment had never had access to: one that could match each transaction to the acquirer most likely to approve it in real time, while maintaining the fraud and chargeback posture required to keep Visa and Mastercard scheme monitoring programmes inactive.

PROBLEM

User problem

Merchants in MCC 7995 were experiencing debit card authorisation rates below 80% – not because of fraudulent cardholders, but because their single assigned acquirer applied blanket decline rules across the entire category regardless of individual transaction risk. In many cases a Barclays UK debit card from a returning player with 14 prior successful deposits received identical treatment to a first-time prepaid virtual card. Merchants had no visibility into decline reasons and no fallback route.

Business problem

Static single-acquirer assignment produces measurably sub-optimal commercial outcomes. Transaction data shows approval probability for the same BIN – Barclays, MCC Gambling, £0–50 – varying from 92% on one acquirer to 81% on another. That differential was not being captured. Every misrouted transaction was recoverable revenue destroyed by an infrastructure gap rather than by genuine issuer risk. Each percentage point of lost authorisation rate represented a direct and recoverable commercial loss – recoverable with the right routing architecture, but not recoverable within a single-acquirer model.

Technical and operational problem

Solving this required reframing routing as an expected value maximisation problem rather than a configuration problem. The orchestration layer needed to evaluate a composite score across five probability models – approval, fraud, chargeback, retry success, and velocity – for each candidate acquirer, in milliseconds, on every transaction. Acquirer credential isolation had to be maintained per merchant and per environment without conditional logic in the live transaction flow. The absence of live merchant volume at programme inception meant routing assumptions had to be proven from first principles rather than from observed data – a sequencing constraint that shaped every architectural decision.

APPROACH

Reframing the routing objective: expected net value, not approval rate

The foundational programme decision was defining what the routing engine optimises before any architecture was committed. The engine does not maximise approval rate. It maximises expected net value to the gateway per transaction , the margin remaining after subtracting expected fraud losses, chargeback costs, and acquirer processing fees:

EV = (P_approve × Net margin per approved transaction) − (P_fraud × FraudLoss) − (P_cb × ChargebackCost)

Where net margin = gateway processing fee − acquirer fee. Every term except net margin and acquirer fee is a probability estimate, recalculated fresh on every transaction. On a £100 gambling deposit, this distinction is decisive: Acquirer C at 94% approval with high fraud and chargeback exposure generates negative EV. Acquirer B at 86% approval with low fraud and chargeback exposure generates materially positive EV. Routing to Acquirer C destroys gateway margin while appearing to perform on the headline metric.

The five probability models

The EV formula draws on three probability models. Two further models , velocity scoring and retry success , gate transactions before routing and recover value after soft declines respectively. All five are described below. All five share one mathematical foundation: Bayesian updating.

Bayesian updating , the mathematical foundation of all five models

Every probability estimate in the system is maintained as a Beta distribution with two parameters:

• α = number of times the outcome of interest was observed (approval, fraud, chargeback, retry success)
• β = number of times the outcome was not observed

The current best estimate of the probability is:

After each new transaction outcome arrives, one parameter increments by 1:

• Outcome observed → α = α + 1
• Outcome not observed → β = β + 1

The estimate recalculates immediately. This means every model is continuously learning , each transaction makes the next routing decision more accurate. Before any real transactions flow, the model is seeded with pseudo-counts derived from acquirer benchmark data and industry benchmarks, giving the system an informed starting point rather than a blank slate.

The Bayesian approach is superior to a simple frequency count for one critical reason: it is confidence-aware. A model with α=9, β=1 (90% from 10 observations) knows its estimate is uncertain. A model with α=900, β=100 (90% from 1000 observations) knows its estimate is reliable. The routing engine can weight high-confidence estimates more heavily than low-confidence ones , particularly important on sparse transaction profiles where little historical data exists.

The five models in detail

1. Approval

P(approval | BIN, Acquirer, MCC, Amount, Country, Device, 3DS, Velocity)

The probability that a specific acquirer will approve this specific transaction given its live profile. This is the primary input to the routing matrix , the lookup table that stores historical approval rates per BIN/MCC/amount band/acquirer combination. The routing matrix is not static. Every completed transaction updates the relevant α and β counts, so the approval rate estimates continuously improve. The same Barclays BIN routes differently at £0–50 versus £50–200 because the matrix learns issuer behaviour at that granularity. When a transaction profile has never been seen before, the engine relaxes input variables one at a time , from specific to general , until a matching row is found.

2. Fraud

P(fraud | Device, Velocity, Geo, BIN, Amount, Merchant, Behaviour)

The probability that this transaction is fraudulent based on observable signals. Fraud labels arrive with a 30–90 day lag , confirmed via chargeback reason codes or acquirer fraud flags , meaning the model trains on older data and relies on leading indicator signals observable right now. Velocity anomaly, device fingerprint, and geo mismatch are the strongest real-time fraud signals precisely because they are observable at transaction time without waiting for outcome confirmation. Note: acquirer is deliberately excluded from the fraud model inputs because fraud risk is a property of the transaction, not the routing decision. However, acquirer fraud flag sensitivity varies , different acquirers flag at different thresholds , which creates a label normalisation requirement when updating fraud probability estimates from acquirer-reported data.

3. Chargebacks

P(chargeback | Merchant, PlayerType, Issuer, MCC, Amount, History)

The probability of a downstream chargeback dispute. Distinct from fraud , chargebacks are initiated by legitimate cardholders disputing charges through regret, friendly fraud, or genuine service failures. Chargeback labels carry the longest lag of all models: 30–120 days. The model compensates with strong leading indicators observable at transaction time: first-time depositor status, credit card type, prior friendly fraud history, and the merchant’s own rolling chargeback ratio. Critically, P(chargeback) is not just a per-transaction cost , it is a MID survival signal. Scheme monitoring programmes trigger at portfolio-level chargeback ratios. The RouteScore weighting w₃ can be increased for merchants approaching these thresholds, aggressively penalising high-chargeback profiles even at the cost of approval rate.

4. Velocity

VelocityScore = Transactions_window / ExpectedTransactions_window

A real-time ratio metric , not a Bayesian probability model , that measures how far a cardholder’s current transaction frequency deviates from their expected baseline. A score of 9 (18 actual deposits per hour vs 2 expected) flags high anomaly. VelocityScore serves two roles: as a hard pre-routing gate when it exceeds a defined threshold (ERR_RISK_REJECTED before any acquirer API call), and as an input signal into P(fraud). It is the fastest-responding signal in the system because it requires no outcome label , anomaly is detectable in real time from transaction counts alone.

5. Retry Success

P(retry_success | DeclineCode, Issuer, Acquirer, TimeDelay, 3DS)

When an acquirer returns a soft decline code, the retry model scores three candidate paths: same acquirer immediately, alternative acquirer immediately, and time-delayed retry. It selects the path with the highest predicted success probability. The model updates immediately after each retry outcome , making it the fastest-updating Bayesian model in the system. Retry scoring is governed by card scheme retry rules that limit how many retry attempts are permitted per transaction within a time window. The model therefore gates retries not just on probability of success but on whether the expected value of the retry attempt , net of fraud and chargeback risk , justifies consuming a retry quota slot.

The explore vs exploit tradeoff: building the routing matrix

The routing matrix can only estimate P(approval) for an acquirer on a given transaction profile if transactions have actually been sent to that acquirer on that profile. This creates a cold-start problem: routing everything to the best known acquirer means never learning whether an alternative acquirer might perform better on specific profiles.

The programme addressed this through deliberate traffic splitting using an epsilon-greedy strategy. A defined percentage ε of transactions are routed to exploration acquirers , not the highest EV choice , specifically to generate observed approval rate data across the full acquirer pool. The remainder exploit the current best known routes.

Exploration rate starts higher early in the programme when the matrix is sparse, and decays automatically as transaction volume grows and estimates become reliable. This is an explicit commercial tradeoff: short-term EV is sacrificed on exploration transactions in exchange for a routing matrix that improves in accuracy over time. The routing matrix was seeded at launch with acquirer benchmark data provided during commercial onboarding , informed priors that gave the system a starting point before live transaction data was available.

The RouteScore formula: how all five models combine into one decision

The EV formula produces a raw expected value per acquirer. But EV alone is not always the right decision criterion. A merchant approaching a Visa chargeback threshold needs the platform to weight chargeback avoidance more heavily than raw margin. A VIP player deposit warrants prioritising approval rate over cost sensitivity. The RouteScore formula applies configurable weights to each dimension:

RouteScore = (w₁ × P_approve) − (w₂ × P_fraud) − (w₃ × P_cb) − (w₄ × AcquirerCost) + (w₅ × CustomerValue)

The weights w₁–w₅ are operator-configured per merchant vertical. They do not change the underlying probability estimates , those are fixed by the Bayesian models. They change how much each dimension contributes to the final routing decision. The acquirer with the highest RouteScore wins, not necessarily the highest EV acquirer. This is the operator’s judgment encoded as numbers , translating commercial priorities into routing behaviour without touching the probability models themselves.

How RouteScore and EV relate

EV and RouteScore answer different questions:

• EV asks: “What is the expected net profit of routing to this acquirer?”
• RouteScore asks: “Given our current commercial priorities, which acquirer should we route to?”

When weights are set neutrally , equal importance to all dimensions , RouteScore approximates EV. When weights are tuned , for example, w₃ increased for a merchant near chargeback threshold , RouteScore diverges from EV deliberately. The platform may route to a slightly lower EV acquirer that carries lower chargeback risk, accepting a small margin sacrifice to protect MID health.

This is the operator judgment layer that sits above the mathematics. The probability models tell the truth about each acquirer’s historical performance. The RouteScore weights determine which truth matters most on this transaction, for this merchant, right now.

Sequencing irreversible dependencies ahead of visible features

Consumer-facing merchant tooling was explicitly deferred until the routing core was stable. The GatewayRouterService was designed so that per-merchant acquirer assignment lives in the data model, not in application logic, enabling acquirer reassignment and A/B routing experiments without code deploys. Five specialist acquirers were evaluated and costed alongside the two live integrations.

The RouteScore formula is the final decision layer. It sits above all five probability models and the EV formula. Understanding it requires understanding what it is – and what it is not.

What RouteScore is not

RouteScore is not a separate probability model. It does not estimate the likelihood of any outcome. It does not learn from transaction data directly. It is a weighted aggregation formula that combines the outputs of the probability models into a single comparable score per acquirer.

What RouteScore is

RouteScore is the operator’s commercial judgment, expressed mathematically. It takes the raw probability estimates from the Bayesian models and applies weights that reflect current business priorities.

RouteScore = (w₁ × P_approve) − (w₂ × P_fraud) − (w₃ × P_cb) − (w₄ × AcquirerCost) + (w₅ × CustomerValue)

Each term in this formula is either a probability from one of the Bayesian models or a fixed known value:

Term	Source	Type
P_approve	P(approval) model	Bayesian probability, live
P_fraud	P(fraud) model	Bayesian probability, lagged
P_cb	P(chargeback) model	Bayesian probability, most lagged
AcquirerCost	Commercial contract	Fixed known value
CustomerValue	Player profile data	Calculated from history

What the weights actually do

Each weight is a multiplier that amplifies or dampens the contribution of that term to the final score.

Consider two scenarios with identical probability estimates but different weights:

Scenario A – Normal operations, w₁=1.0, w₂=1.0, w₃=1.0, w₄=0.5, w₅=0.5

The platform weights approval, fraud, and chargeback equally. Cost and customer value play a smaller role. The engine selects the acquirer with the best balanced risk-adjusted outcome.

Scenario B – Merchant approaching chargeback threshold, w₁=0.8, w₂=1.0, w₃=2.0, w₄=0.5, w₅=0.5

The chargeback penalty is doubled. The engine will accept lower approval rates and slightly higher fraud risk in exchange for routing away from high-chargeback profiles. MID survival takes priority over margin.

The probability estimates have not changed. The acquirer’s actual performance has not changed. Only the operator’s judgment about what matters most right now has changed – and that judgment is encoded in the weights.

How RouteScore relates to EV

The EV formula is embedded inside RouteScore. You can see it if you set w₁ = net margin, w₂ = FraudLoss, w₃ = ChargebackCost, w₄ = 1, w₅ = 0:

RouteScore → EV = (P_approve × Net margin) − (P_fraud × FraudLoss) − (P_cb × ChargebackCost) − AcquirerCost

Pure EV maximisation is a special case of RouteScore where the weights are set to the financial values of each outcome. RouteScore generalises EV by allowing the operator to adjust those weights based on non-financial priorities — MID health, VIP treatment, risk appetite — that pure financial EV does not capture.

The complete decision sequence

1. Transaction arrives with live profile
2. VelocityScore calculated — if above threshold, block. If below, continue.
3. For each candidate acquirer, the three Bayesian models return P_approve, P_fraud, P_cb
4. EV calculated per acquirer using those probabilities and known financial values
5. RouteScore calculated per acquirer using those same probabilities plus operator weights
6. Acquirer with highest RouteScore selected — not necessarily highest EV, not necessarily highest approval rate
7. Transaction dispatched to selected acquirer
8. Outcome received — approved, soft decline, or hard decline
9. If soft decline: P(retry_success) model scores three retry paths, selects highest, re-enters routing
10. If approved or hard declined: Bayesian models update α or β for this profile on this acquirer
11. Routing matrix updated — next transaction on this profile benefits from this outcome

Every step feeds the next. The system improves continuously because step 10 and 11 never stop running.

ARCHITECTURE

Diagram 1 – Statistical routing matrix

The routing matrix is the lookup table the scoring engine reads at decision time. It stores historical approval rates for every observed combination of BIN, MCC, amount band, and acquirer – updated after every completed transaction. The engine does not calculate approval probability from first principles on each request. It reads the nearest matching row from this table, feeds that approval rate into the EV formula alongside fraud and chargeback probabilities, and selects the highest-EV route. The table below shows a representative slice.

BIN	MCC	Amount band	Acquirer	Historical approval rate
Barclays UK debit	Gambling 7995	£0–50	Acquirer 1	92%
Barclays UK debit	Gambling 7995	£0–50	Acquirer 2	81%
Barclays UK debit	Gambling 7995	£50–200	Acquirer 1	84%
Barclays UK debit	Gambling 7995	£50–200	Acquirer 2	67%
Monzo debit	Sports betting 7995	£0–100	Acquirer 2	89%
Monzo debit	Sports betting 7995	£0–100	Acquirer 1	82%
Revolut virtual	Gambling 7995	£0–50	Acquirer 2	92%
Revolut virtual	Gambling 7995	£0–50	Acquirer 1	77%

The table makes visible what static routing cannot see: the best acquirer for a Barclays debit card is not the best acquirer for a Revolut virtual card. Without this matrix, every transaction takes the same route regardless of these differentials. With it, each transaction is routed to the acquirer statistically most likely to approve it – and every outcome updates the table, so the next similar transaction is routed from better data.

Diagram 2 – Transaction processing pipeline

This diagram shows how a transaction flows from merchant API call through the pre-risk engine, deduplication, route scoring, acquirer dispatch, and soft decline recovery. The pre-risk engine and deduplication run before routing – not after – because a transaction blocked post-routing contaminates the routing matrix with a data point reflecting operational failure rather than genuine issuer behaviour, distorting future approval rate estimates for that BIN/acquirer combination.

Diagram 3 – Probability models and EV composition

This diagram shows how the five probability models compose into the EV formula, route score, and final routing decision. The routing matrix sits at the centre – updated by transaction outcomes on the right and read by the approval model on the left – making the system self-improving with each completed transaction. Storing routing configuration in the data model rather than application logic was the decision that made this feedback loop possible without code deploys.