Approval rates are the single most important metric in forex payment processing. Every declined deposit is a trader who wanted to fund their account and was told “no” -- not by the broker, but by the payment infrastructure sitting between the trader's bank and the broker's account. The industry average for forex card deposits hovers around 65-72%, meaning roughly one in three deposit attempts fails. At Proxy.forex, our network-wide approval rate sits at 91.4%, and our best-performing broker configurations consistently exceed 95%.

The difference is smart routing. In this article, I will walk through the technical architecture of our ML-based routing engine, explain the features that drive routing decisions, describe how cascading logic recovers declined transactions, and share a real-world case study of a broker that went from a 68% approval rate to 96.2% after migrating to our platform. If you are an engineer, product manager, or CTO at a forex broker, this is the technical deep dive you have been looking for.

The Approval Rate Problem in Forex

Forex deposits are inherently high-risk from an issuing bank's perspective. The merchant category code (MCC 6211 for securities/commodity brokers) triggers heightened fraud scrutiny at most issuers. Transactions are frequently cross-border, adding another layer of risk signals. Deposit amounts often exceed typical e-commerce thresholds, and the pattern of repeated deposits from the same cardholder -- a normal behavior for active traders -- can trigger velocity-based fraud rules designed for one-off purchases.

The result is that issuers decline forex deposits at dramatically higher rates than standard e-commerce transactions. A card that works flawlessly for online shopping may be consistently declined when used for a forex deposit. The decline reasons vary -- “do not honor,” “suspected fraud,” “transaction not permitted” -- but the root cause is the same: the issuer's risk model is not confident that the transaction is legitimate, and it defaults to caution.

The critical insight is that the same transaction, presented to the same issuer through a different acquirer, may receive a different decision. This is because each acquirer has a different risk profile, different relationships with issuing banks, different BIN ranges they perform well on, and different fraud screening configurations. The acquirer through which a transaction is routed is not merely a pipe -- it is an active participant in the authorization decision. This is where smart routing creates value.

Why Static Routing Fails

Traditional payment routing is rule-based. A payment processor maintains a configuration table that maps transaction attributes to acquirers: “Visa cards from EU countries go to Acquirer A; Mastercard from APAC goes to Acquirer B; everything else goes to Acquirer C.” These rules are typically configured manually by a payments operations team and updated infrequently -- perhaps monthly or quarterly.

The problem with static routing is that acquirer performance is not static. An acquirer that performs well on UK-issued Visa cards this week may see degraded approval rates next week because their acquiring bank changed its risk thresholds, or because a fraud event in the network triggered tighter screening. Issuer behavior changes with the time of day, the day of the week, and seasonal patterns. New BIN ranges are issued, existing ranges are retired, and card scheme rules evolve continuously.

Static routing cannot respond to these dynamics. It is inherently backward-looking and coarse-grained. By the time a human operator notices that Acquirer A's approval rate on German Visa cards has dropped by 15 points and manually reroutes that traffic to Acquirer B, thousands of transactions have already been declined. Smart routing closes this feedback loop from days to milliseconds.

ML-Based Routing Architecture

Our routing engine operates as a real-time scoring service that sits in the critical path of every transaction. When a deposit request arrives, the router evaluates it against a gradient-boosted decision tree model that has been trained on the historical outcomes of millions of transactions across our network. The model produces a probability score for each available acquirer, representing the estimated likelihood that the transaction will be approved if routed through that acquirer. The transaction is sent to the acquirer with the highest estimated approval probability.

The architecture is designed for low latency. The model is compiled and cached in memory, and feature computation is performed using pre-aggregated statistics stored in Redis. The entire routing decision -- feature extraction, model inference, and acquirer selection -- completes in under 5 milliseconds for 99% of transactions. This is critical because the routing decision is synchronous and sits in the transaction's hot path; any latency added by the router directly impacts the trader's deposit experience.

Model retraining occurs on a continuous schedule. Every four hours, a new model is trained on the latest 72 hours of transaction outcomes, validated against a holdout set, and promoted to production if it outperforms the current model on key metrics (approval rate, revenue impact, calibration accuracy). This continuous learning loop ensures that the model adapts to changes in issuer behavior, acquirer performance, and network-wide patterns without manual intervention.

Features That Drive Routing Decisions

The quality of a routing model is fundamentally determined by the features it uses. Our model evaluates over 60 features for each transaction, organized into several categories. BIN-level features capture the card's issuing bank, country, card type (debit/credit/prepaid), and product level (classic/gold/platinum). Historical performance features aggregate approval rates for the specific BIN-acquirer combination over the past 1, 6, 24, and 72-hour windows, allowing the model to detect both sudden shifts and gradual trends.

Geographic features include the trader's IP-derived country, the card's issuing country, and whether the transaction is domestic or cross-border relative to each available acquirer. Transaction-level features capture the deposit amount, currency, whether it is a first-time or repeat deposit, and the time elapsed since the trader's last deposit. Acquirer-level features track each acquirer's current throughput, error rates, latency, and real-time approval rate relative to their trailing average.

One particularly powerful feature set involves issuer-level behavioral patterns. We maintain rolling statistics on how each issuing bank responds to transactions from each acquirer at different times of day and for different transaction amounts. Some issuers, for example, are significantly more likely to approve transactions during business hours in their local timezone. Others show strong amount-sensitivity thresholds where approval rates drop sharply above certain deposit values. The routing model learns these patterns and exploits them to select the optimal acquirer for each specific transaction context.

Cascading Logic: Recovering Declined Transactions

Even the best routing model cannot achieve 100% first-attempt approval rates. When a transaction is declined by the first-choice acquirer, the cascading engine evaluates whether a retry through an alternative acquirer is likely to succeed. This is not a simple round-robin retry -- the cascading decision is itself an ML-informed process that considers the decline reason code returned by the first acquirer, the specific BIN and issuer involved, and the historical recovery rates for similar decline scenarios.

Certain decline codes are retryable with high recovery probability. A “do not honor” (response code 05) from Acquirer A may simply indicate that the acquirer's fraud screening rejected the transaction, and the same transaction sent through Acquirer B -- which has a different fraud model and a different relationship with the issuing bank -- may be approved. Our data shows that 35-45% of “do not honor” declines are recovered through intelligent cascading. Conversely, a “lost or stolen card” decline is never retried, as the issue is with the card itself rather than the routing.

The cascading engine also respects configurable constraints. Brokers can set maximum retry counts (typically 2-3 attempts), maximum cascade latency budgets (ensuring the trader is not left waiting), and acquirer-level rate limits to avoid overwhelming a single processor. The cascade sequence is determined at the time of the initial routing decision -- the model selects not just the best first-choice acquirer but the optimal ordered list of fallbacks, creating a complete routing plan before the first transaction is attempted.

A/B Testing Acquirer Configurations

When a new acquirer is onboarded or an existing acquirer's configuration is changed, we need to evaluate its performance without risking a large volume of transactions. Our routing engine supports built-in A/B testing capabilities that allow a configurable percentage of traffic to be routed to the new configuration while the remainder continues through the existing routing model.

The A/B test framework computes statistical significance in real time, comparing approval rates, average transaction values, and decline reason distributions between the control and treatment groups. Once the test reaches statistical significance (typically after 500-2,000 transactions depending on the expected effect size), the system can either automatically promote the winning configuration or alert the operations team for manual review. This data-driven approach to acquirer management replaces the traditional method of switching all traffic to a new acquirer and hoping for the best.

Case Study: From 68% to 96.2% Approval Rate

In Q3 2025, a CySEC-regulated forex broker with approximately 12,000 active traders migrated to Proxy.forex from a legacy payment processor. At the time of migration, their blended approval rate across Visa and Mastercard deposits was 68.3%. Their previous processor used static routing with two acquirers, both based in Europe, with no cascading capability.

During the initial onboarding, we analyzed their historical transaction data to understand the profile of their trader base: approximately 40% EU-based, 30% APAC, 20% MENA, and 10% LatAm. The high proportion of cross-border transactions from APAC and MENA regions was a primary driver of their low approval rates -- their European-only acquirer configuration meant that every non-EU transaction was processed cross-border, triggering elevated decline rates from Asian and Middle Eastern issuers.

We configured their routing with five acquirers spanning three regions: two European acquirers optimized for different BIN ranges, one APAC-based acquirer with strong domestic acquiring in Thailand, Malaysia, and Indonesia, one MENA-focused acquirer covering the UAE and Saudi Arabia, and one global fallback acquirer. Within the first week, with minimal model training data, their approval rate jumped to 82.1%. Over the following four weeks, as the routing model accumulated enough data to learn their specific trader base's patterns, the rate climbed steadily to 91.7%.

The breakthrough to 96.2% came with two additional optimizations. First, we enabled intelligent cascading with a maximum of two retries per transaction, which recovered an additional 4.1% of initially declined deposits. Second, we worked with their compliance team to implement 3D Secure selective authentication -- applying 3DS only when required by regulation or when the routing model determined it would improve the authorization outcome -- which eliminated unnecessary friction that was causing legitimate traders to abandon the deposit flow. The 96.2% approval rate has been sustained for over three months with minimal variance.

Monitoring and Continuous Improvement

A routing engine is only as good as its observability. We maintain real-time dashboards that track approval rates by acquirer, BIN range, issuing country, card type, transaction amount band, and time window. Anomaly detection algorithms monitor for sudden shifts in approval patterns -- for example, if an acquirer's approval rate on UK-issued Visa cards drops by more than 5 percentage points within a 30-minute window, an alert is triggered and the routing model automatically reduces traffic to that acquirer while the issue is investigated.

Beyond reactive monitoring, we conduct weekly routing reviews where our payments engineering team analyzes the model's performance, identifies underperforming BIN-acquirer combinations, and evaluates whether new features or acquirer configurations could improve outcomes. These reviews combine automated data analysis with human expertise -- the model handles the high-frequency optimization, but strategic decisions about acquirer relationships and routing policies benefit from human judgment.

Routing API: Request and Response Structure

For brokers integrating with our routing engine via the API, here is a simplified example of the routing request and the enriched response. The broker submits the transaction details, and Proxy.forex returns the selected acquirer along with the routing rationale and cascade plan.

// POST /v1/deposits/route
{
  "merchant_id": "broker_12345",
  "amount": 500.00,
  "currency": "USD",
  "card": {
    "bin": "411234",
    "last_four": "5678",
    "brand": "visa",
    "type": "credit",
    "issuer_country": "GB"
  },
  "trader": {
    "id": "trader_98765",
    "ip_country": "GB",
    "deposit_count": 3,
    "lifetime_volume": 1200.00
  }
}

// Response
{
  "route_id": "rt_abc123def456",
  "selected_acquirer": "acq_eu_primary",
  "confidence_score": 0.94,
  "estimated_approval_probability": 0.91,
  "cascade_plan": [
    { "priority": 1, "acquirer": "acq_eu_primary", "score": 0.94 },
    { "priority": 2, "acquirer": "acq_eu_secondary", "score": 0.87 },
    { "priority": 3, "acquirer": "acq_global_fallback", "score": 0.72 }
  ],
  "routing_factors": [
    "domestic_acquiring_match",
    "high_bin_approval_history",
    "optimal_time_window"
  ],
  "three_ds_recommendation": "not_required"
}

The response includes the confidence score (how certain the model is in its selection), the full cascade plan with fallback acquirers ranked by estimated approval probability, the key factors that influenced the routing decision, and a 3D Secure recommendation. This transparency allows brokers to understand not just where a transaction was routed, but why -- which is invaluable for debugging decline issues and optimizing payment configurations.