Every payment that a European customer makes online sits at the intersection of two competing forces. On one side is regulation, which exists because unauthenticated card-not-present fraud grew for years into a genuine, continent-wide problem, and which now legally requires many transactions to be verified with more than a single factor. On the other side is user experience, because every additional step a customer has to complete before checkout finishes is a chance for that customer to abandon the purchase entirely. A payments platform operating across the European Economic Area has to satisfy both forces simultaneously, and the system that does this well looks nothing like a simple “always ask for a one-time code” implementation. It looks like a risk-aware authentication engine that can tell, transaction by transaction, whether strong authentication is legally required, commercially advisable, or entirely unnecessary.

A Short History of the Regulation

The requirement at the centre of this system traces back to the second Payment Services Directive, widely known by its abbreviation, which the European Union adopted to modernise and harmonise payment services across member states. Before this directive, authentication practices for online card payments varied enormously between banks and merchants: some relied purely on a card number and a security code, others used static passwords that rarely changed and were frequently reused across other websites, and fraud losses from card-not-present transactions grew steadily as e-commerce grew.

The directive’s Regulatory Technical Standards on strong customer authentication introduced a precise legal definition: authentication that uses at least two independent elements drawn from three categories — something the customer knows, such as a password or PIN, something the customer has, such as a mobile device or hardware token, and something the customer is, such as a fingerprint or facial biometric. Crucially, the regulation also required dynamic linking, meaning the authentication itself must be cryptographically tied to the specific amount and specific payee of that particular transaction, so that an authentication code generated for one purchase cannot be reused or replayed against a different purchase.

What makes this regulation particularly interesting from a systems design perspective is that it was written with explicit, carefully negotiated exemptions built in from the start, precisely because regulators understood that mandating strong authentication on every single transaction, without exception, would meaningfully harm legitimate commerce and customer experience. This is unusual for a security regulation; most security mandates simply raise the bar uniformly. This one instead creates a structured decision problem: for any given transaction, is it in scope, and if it is in scope, does it qualify for one of several defined exemptions. Building a system that answers this question correctly, quickly, and defensibly for every transaction is the actual engineering challenge this guide addresses.

Why This Became a Systems Design Problem, Not Just a Compliance Checkbox

In the earliest implementations following the regulation’s rollout, many merchants and payment providers took the simplest possible path: force strong authentication on every transaction, regardless of risk or exemption eligibility, simply to guarantee compliance and shift liability for fraud losses onto the card issuer. This approach was legally safe but commercially damaging, since checkout abandonment rates rose noticeably wherever an extra authentication step was inserted into a previously frictionless flow. Over time, the industry converged on a much more sophisticated approach: real-time transaction risk analysis that dynamically decides, for each individual transaction, whether an exemption applies and whether the issuing bank is likely to accept that exemption, only falling back to full strong authentication when genuinely necessary. This shift from blanket enforcement to risk-based, adaptive enforcement is exactly what transforms this topic from a simple compliance checkbox into a genuine, interesting distributed systems and machine learning problem.

A Cross-Border, Multi-Party Coordination Problem

Part of what makes this domain genuinely difficult from an engineering standpoint is that no single party in the transaction chain has complete authority or complete information. The merchant’s payment provider can request an exemption but cannot force the issuing bank to grant it. The issuing bank can decide the outcome for its own cardholder but has no visibility into the provider’s aggregate risk model or the specific merchant relationship history. The card scheme operating the shared authentication protocol has to accommodate every provider’s and every issuer’s differing risk appetites within a single, standardised message format. Building a system that functions well within this multi-party, partially-observable coordination problem requires engineering discipline that goes well beyond what a typical single-organisation system needs, since the platform being designed here must anticipate and gracefully handle decisions made by external parties it cannot control, predict with certainty, or directly test against in the way it can test its own internal components.

This multi-party nature also means the system’s design has to be defensive by construction. A well-formed authentication request might still be rejected by an issuer for reasons entirely outside the provider’s own risk assessment, perhaps because that specific issuer applies a more conservative internal policy, or because the cardholder has a fraud flag on their account that the provider has no visibility into. The system must never assume its own risk assessment is the final word, and must always be ready to seamlessly transition into a fallback path the moment an external party disagrees.

It is also worth noting that this coordination problem is not static; it evolves as card schemes update their shared protocol, as individual issuers adjust their own internal risk appetite in response to their own observed fraud trends, and as regulators themselves periodically clarify or amend specific aspects of the technical standards through updated guidance. A platform’s authentication system therefore cannot be built once and left alone; it needs an organisational process, not just a technical one, for staying current with an ecosystem that several independent, powerful parties are all simultaneously and continuously adjusting.

Before designing the system, it is worth being precise about the actual decision logic the regulation requires, because the system’s entire architecture exists to compute this decision correctly and quickly for every transaction.

What Falls In Scope

Strong authentication is generally required whenever a payer initiates an electronic payment within the European Economic Area and the transaction is what regulators call “two-leg,” meaning both the customer’s bank and the merchant’s bank are located within the region. Transactions where only one side is within the region — commonly called one-leg transactions, such as a European customer paying a merchant whose acquiring bank sits outside the region — generally fall outside the strict mandate, though many platforms choose to apply authentication anyway for risk management reasons independent of the legal requirement.

It is also worth understanding a handful of transaction categories the regulation treats as inherently out of scope regardless of value or risk, because they do not fit the customer-present, electronic-remote-payment model the framework was designed around in the first place. Mail-order and telephone-order transactions, where the customer provides card details verbally or in writing rather than through an interactive electronic channel, are generally treated as outside the scope of this specific mandate, though they remain subject to other applicable fraud-prevention obligations. Anonymous, low-value prepaid payment instruments below certain defined thresholds are similarly excluded, reflecting a policy judgment that the potential fraud exposure from such instruments is inherently capped by their low face value. Understanding these structural exclusions matters because a system that naively tries to apply the exemption-evaluation framework to every single transaction, including ones that were never in scope to begin with, wastes processing effort and can occasionally produce confusing, technically incorrect decision trails that complicate later compliance review.

The Recognised Exemptions

Several categories of transaction can be exempted from mandatory strong authentication, each with its own precise conditions.

Who Ultimately Decides

An important and often misunderstood detail is that the merchant’s payment provider can request an exemption, but the customer’s card-issuing bank makes the final decision on whether to honour it. If the issuer disagrees with the risk assessment, it can decline the exemption and force strong authentication anyway, which means the system being designed here has to gracefully handle a “soft decline requiring step-up authentication” response and seamlessly transition the customer into an authentication flow mid-transaction, rather than treating exemption requests as guaranteed outcomes.

Categories of Transaction and Their Typical Treatment

It is useful to build a mental table of common transaction types and how the framework generally treats each, since this intuition guides much of the system’s internal routing logic. Building this table early in a project, and keeping it visible and current for the whole engineering team, tends to prevent a surprisingly common category of bug where a new transaction type is added to the platform without anyone explicitly deciding, and documenting, which scope and exemption path it should follow.

The Liability Shift Mechanism

A further nuance worth understanding is how liability for fraud losses shifts depending on how the authentication decision was made. When strong authentication is properly applied and completed successfully, liability for a subsequently disputed fraudulent transaction generally shifts toward the party who failed to prevent the fraud despite authentication having occurred correctly, which in practice often protects the merchant and provider. When an exemption is used instead, whichever party chose to bypass authentication — whether that is the provider by requesting the exemption or the issuer by granting it — generally retains more exposure to the resulting liability if the transaction turns out to be fraudulent. This liability asymmetry is precisely why exemption requests are not simply “free” from the provider’s perspective, and why the risk analysis engine has to weigh not just whether an exemption is legally available, but whether taking on the associated liability shift is commercially sound for this specific transaction.

A production-grade strong customer authentication system is best understood as a decisioning layer sitting between the checkout flow and the actual authentication challenge, backed by a real-time risk engine, an exemption-eligibility tracker, and a resilient integration with the wider 3-D Secure ecosystem that connects merchants, card schemes, and issuing banks.

It is worth emphasising that this decisioning layer is deliberately positioned as a distinct architectural concern from both the checkout experience itself and the core payment authorization pipeline, even though all three are tightly coupled in the customer’s actual end-to-end journey. Keeping authentication decisioning as its own well-bounded layer allows it to evolve, be tested, and be audited independently of unrelated changes to checkout page design or to core payment processing logic, which matters enormously given how frequently regulatory guidance, card scheme protocol versions, and internal risk models each individually change on their own separate timelines.

Component Breakdown

The internal decision logic for a single transaction can be understood as a layered funnel, where each layer either resolves the transaction or passes it down to the next, more expensive layer.

Layer One: Scope Check

The very first thing the orchestration service does is determine whether the transaction is even subject to the mandate at all. This is a fast, deterministic check based on structural properties of the transaction: the location of the issuing and acquiring banks, whether the transaction is customer-present or merchant-initiated, and whether the payment instrument itself is explicitly excluded, such as certain low-value anonymous prepaid cards. Out-of-scope transactions bypass the entire authentication decision and proceed straight to authorization, since applying the framework to them would be both unnecessary and, in some cases, technically impossible given the transaction type.

Layer Two: Hard Exemption Eligibility

For in-scope transactions, the regulatory rules engine checks, in strict order, whether any hard, unambiguous exemption applies: is this payee on the customer’s trusted beneficiary list, is this a subsequent payment in an already-authenticated recurring mandate, or does this transaction fall under the corporate payment exemption. These checks are deterministic and legally precise, since getting them wrong in the permissive direction risks regulatory non-compliance, while getting them wrong in the restrictive direction unnecessarily adds friction the regulation never actually required.

Layer Three: Risk-Based Exemption Evaluation

If no hard exemption applies, the transaction risk analysis engine evaluates whether a discretionary, risk-based exemption should be requested. This step combines the transaction’s value against the low-value threshold, the provider’s currently qualified transaction-risk-analysis threshold (itself a function of the recently measured fraud rate), and the ML model’s individual risk score for this specific transaction. Only if the transaction value sits below the applicable threshold and the ML model’s risk score sits below an internally tuned confidence bar does the system proceed to request an exemption from the issuer rather than triggering a full authentication challenge.

Layer Four: Issuer Adjudication

Even when the provider requests an exemption, the request is only advisory; it is forwarded to the issuing bank as part of the authentication request message, and the issuer makes the final, authoritative decision on whether to honour it, based on its own independent risk assessment of the cardholder and the transaction. The system must be built to accept either outcome gracefully: an “exemption accepted” response that allows the transaction to proceed frictionlessly, or a “step-up required” response that seamlessly transitions the customer into a live authentication challenge.

Layer Five: Challenge Execution

When strong authentication is genuinely required, either because no exemption was available or because the issuer rejected the requested exemption, the orchestration service hands control to the 3-D Secure flow, presenting the customer with a challenge, most commonly an out-of-band prompt in a banking app or a one-time code, cryptographically bound to the exact transaction amount and payee through the dynamic linking requirement described earlier. Only a successful challenge response allows the transaction to proceed to authorization.

Handling Ambiguous or Partial Responses

Not every response from the wider authentication ecosystem is a clean success or clean failure. An issuer’s access control server might return an ambiguous status indicating the challenge is still pending customer action, particularly for out-of-band methods where the customer has to separately open a banking app to approve the transaction, which can take anywhere from a few seconds to, in rare cases, several minutes. The orchestration service handles this by maintaining a bounded polling or webhook-driven waiting window, keeping the checkout experience responsive with clear status messaging, and applying a firm timeout beyond which the transaction is treated as failed rather than left in an indefinitely pending state that could otherwise be exploited or simply create a poor customer experience.

Designing the Waiting Experience

The period during which a customer has been sent an out-of-band challenge but has not yet responded deserves deliberate design attention in its own right, since a poorly handled waiting experience is a common, avoidable source of abandonment even when the underlying authentication itself would have succeeded. Clear, honest messaging that tells the customer exactly what to do — such as explicitly naming the banking app they should check — combined with a visible countdown or progress indicator rather than an ambiguous spinner, measurably improves completion rates. Some platforms also send a lightweight, complementary notification through a second channel, such as a browser or in-app push notification, specifically to reduce the chance a customer simply forgets to check their banking app during the waiting window, though this is layered on top of, never a replacement for, the primary out-of-band challenge itself.

Recomputing Risk After a Step-Up

Interestingly, even after a transaction is routed into a full authentication challenge, the risk analysis engine’s earlier assessment is not discarded. The eventual outcome — whether the challenge succeeds, fails, or is abandoned partway through — is fed back as a labelled training signal, since a transaction the model scored as low risk that nonetheless failed authentication is a particularly valuable data point for identifying where the model’s current risk assessment is diverging from real-world outcomes.

Tracing a single transaction from checkout submission through to final authorization clarifies exactly where each decision is made and how quickly the system needs to make it.

Stage-by-Stage Description

Submission stage: the customer’s payment details and the merchant’s transaction context, including amount, currency, and payee identity, are captured at checkout and forwarded to the orchestration service.

Scope determination stage: a fast, deterministic check establishes whether the strong authentication mandate applies at all, filtering out one-leg transactions, merchant-initiated transactions, and other explicitly excluded categories before any further processing occurs.

Exemption evaluation stage: for in-scope transactions, the risk analysis engine determines whether a hard exemption applies, and if not, whether a discretionary, risk-based exemption should be requested, drawing on the provider’s currently qualified thresholds and the ML model’s assessment of this specific transaction.

Authentication request stage: the orchestrator constructs a standardised authentication request, including the exemption flag if one is being requested, and routes it through the directory server to the correct card issuer based on the card’s identifying information.

Issuer decision stage: the issuing bank’s access control server independently evaluates the request, either honouring the requested exemption for a frictionless outcome or requiring a live authentication challenge.

Challenge stage: when required, the customer completes an authentication challenge, most often through their banking app or a one-time code, cryptographically linked to the specific transaction so the resulting authentication cannot be reused elsewhere.

Authorization stage: once authentication is either exempted or successfully completed, the transaction proceeds to standard payment authorization against the customer’s account.

Logging and reporting stage: every decision made along this path, including which exemption was requested, whether it was granted, and the underlying risk score, is recorded for later regulatory reporting and for feeding back into the fraud rate calculation that determines future exemption thresholds.

A risk-based, exemption-aware authentication system is significantly more complex than a blanket “always authenticate” approach, and that complexity has to be justified by real business and customer benefit.

Balancing Regulatory Certainty Against Commercial Optimisation

A conservative implementation that always defers to a live authentication challenge whenever there is any doubt about exemption eligibility minimises regulatory risk but maximises friction. An aggressive implementation that requests exemptions whenever legally possible, regardless of the ML model’s individual risk assessment, minimises friction but risks a higher issuer rejection rate and a higher true fraud rate that could eventually push the provider’s own qualifying threshold down. The system described in this guide is deliberately positioned in between: legally eligible for an exemption is treated as necessary but not sufficient, and the ML model’s own risk assessment must also clear an internally tuned bar before an exemption is actually requested.

A payments platform operating at continental scale across Europe can see authentication decisions requested at a rate reaching well into the millions per minute during peak retail periods, and the entire scope-to-decision pipeline typically has to complete within a strict latency budget of a few hundred milliseconds to avoid perceptibly slowing down checkout.

Scaling the Risk Analysis Engine

The risk analysis engine is deployed as a horizontally scalable stateless service, with the ML model served through a low-latency inference layer that keeps per-transaction scoring comfortably under ten milliseconds, since this scoring sits directly in the synchronous checkout path and cannot be allowed to become the dominant source of latency.

Scaling the Exemption Eligibility Store

Because per-card cumulative exemption counters must be read and updated for every relevant transaction, this store is sharded by card identifier, allowing near-linear horizontal scalability, with careful attention to keeping updates atomic so that rapid, near-simultaneous transactions on the same card cannot each independently read a stale counter and jointly exceed the cumulative exemption limit the regulation requires to be enforced.

Scaling the 3-D Secure Integration Layer

Communication with the directory server and issuer access control servers, being external network calls to systems the platform does not control, is the least predictable part of the latency budget. This layer is built with aggressive timeouts, circuit breakers per issuer, and a fallback strategy that treats an unresponsive issuer as requiring a step-up challenge by default, since failing safe toward requiring authentication is the legally and commercially safer failure mode than silently allowing an unauthenticated transaction through.

Caching Regulatory Thresholds

The provider’s currently qualified low-value and transaction-risk-analysis thresholds change relatively infrequently, typically recalculated on a rolling basis rather than per transaction, so these values are cached aggressively in the risk analysis engine’s local memory and refreshed on a short interval, avoiding a database round trip on every single transaction for a value that rarely changes moment to moment.

Latency Budgeting

A useful mental model allocates the end-to-end latency budget explicitly: a small fraction for scope determination, a larger fraction for ML risk scoring, a further fraction for the regulatory rules engine, and the remainder as buffer for the external issuer round trip when a request, rather than a bypass, is actually needed. Any change to the pipeline is evaluated against whether it would meaningfully eat into this budget before being approved for production.

Regional Traffic Patterns and Time-Zone-Aware Capacity Planning

Unlike a single global platform serving a fairly uniform worldwide traffic pattern, a European payments platform sees pronounced daily and weekly traffic waves that shift across time zones as the region spans from the western edge of the continent to its eastern edge, and additionally sees pronounced national holiday effects that differ from country to country. Capacity planning for this system therefore has to account for these overlapping, partially independent traffic waves rather than assuming a single, simple daily peak, and autoscaling policies are tuned to respond quickly enough to genuine demand surges, such as a major national retail event in one specific country, without needing to provision worst-case capacity uniformly across the entire platform at all times.

Handling Peak Retail Events

Major seasonal shopping events create some of the most demanding conditions this system will face, combining extremely high legitimate transaction volume with a correspondingly elevated rate of attempted fraud, since attackers are well aware that fraud detection systems can occasionally be pushed toward looser thresholds under sheer volume pressure if not carefully engineered to resist that temptation. The system is load tested specifically against simulated peak-event traffic well before each major seasonal event, with particular attention paid to whether the risk analysis engine’s decision quality degrades under load, not just whether its raw throughput holds up, since a system that stays fast but becomes less accurate under pressure has simply traded one failure mode for another.

Because this system sits directly in the checkout path for a large fraction of European e-commerce, any availability failure translates immediately into lost sales, making resilience a first-order design concern rather than an afterthought.

Handling Issuer and Directory Server Outages

Individual issuing banks or the shared directory server infrastructure can experience their own outages entirely outside the platform’s control. The orchestration service is built with per-issuer circuit breakers, so that a slow or failing issuer does not exhaust connection pools or thread capacity needed to serve transactions routed to entirely unrelated, healthy issuers, and clear fallback behaviour, typically declining or deferring the specific affected transactions rather than allowing a single issuer’s outage to degrade the platform globally.

Exemption Store Reliability

The exemption eligibility store, holding the stateful counters the regulation requires to be tracked accurately, is deployed with quorum-based replication so that no single node failure causes counters to be lost or reset, which could otherwise either incorrectly deny a legitimately available exemption or incorrectly grant one beyond what the regulation actually permits.

Graceful Degradation of the ML Model

If the ML risk-scoring service becomes temporarily unavailable, the system falls back to a more conservative, rules-only exemption decision, generally requesting exemptions only for the most clearly low-risk categories such as small recurring payments to already-trusted payees, rather than failing the entire authentication decisioning pipeline outright.

Disaster Recovery and Regional Failover

Given the platform operates across many European jurisdictions, the orchestration and risk analysis services are deployed across multiple regions, with regular failover drills to confirm that a regional outage does not silently disable authentication decisioning for merchants and customers in that region, and that failover does not introduce inconsistent counter state between regions for cards that could plausibly transact through either.

Backup and Recovery for Compliance-Critical Data

The regulatory reporting logs and exemption decision trail are among the most operationally sensitive data this system produces, since their loss would not just be an internal inconvenience but could leave the organisation unable to demonstrate compliance during a regulatory audit. These records are backed up with a longer retention window than typical operational data, generally matching or exceeding the regulatory record-keeping requirement for the jurisdiction in question, and recovery procedures for this specific data are tested separately from general disaster recovery drills, since a compliance-focused audit of these records tends to happen on a very different timeline and with very different expectations than a typical operational incident review.

Handling Partial Ecosystem Degradation

Because this system depends on external infrastructure it does not control, namely the shared directory server and the many individual issuer access control servers, it must be resilient not just to total outages but to partial, degraded states, such as an issuer responding correctly but unusually slowly. The orchestration service tracks a rolling latency and error-rate profile per issuer, and can proactively route around, or apply a more conservative fallback for, an issuer that is technically up but exhibiting degraded performance, rather than waiting for a hard failure threshold to be crossed before reacting.

The authentication system itself is a high-value target, since compromising or manipulating it could allow an attacker to bypass the very protection the regulation exists to guarantee.

Protecting the Exemption Decision Logic

Access to configuration for exemption thresholds, ML model risk cutoffs, and the regulatory rules engine must be tightly restricted with full audit logging, since an attacker or a malicious insider who could quietly loosen exemption thresholds would effectively be granting themselves, or colluding merchants, the ability to push fraudulent transactions through without triggering a genuine authentication challenge.

Segregation of Duties for High-Impact Configuration Changes

Given how directly exemption threshold and risk model configuration affects both regulatory exposure and fraud loss, no single individual should be able to unilaterally author and deploy a change to this configuration in production. A two-person approval requirement, combined with automated policy checks that flag any threshold change exceeding a predefined safe range for additional scrutiny before it can be approved, provides a meaningful structural defence against both simple human error and deliberate insider misuse, without meaningfully slowing down the routine, well-justified threshold adjustments that are a normal and necessary part of operating this system well over time.

Integrity of the Dynamic Linking Mechanism

Because dynamic linking cryptographically ties an authentication response to a specific amount and payee, the system must guarantee that this binding cannot be tampered with between the moment the customer authenticates and the moment the transaction is authorized; any mismatch between the authenticated amount or payee and the amount or payee actually submitted for authorization must cause the transaction to be rejected outright rather than silently proceeding with the discrepancy.

This guarantee has to hold even against a scenario where the merchant’s own checkout page has been compromised, for example through injected malicious script content, since the entire point of dynamic linking is to protect the customer against exactly this kind of tampering by giving the issuer’s own systems, rather than the potentially compromised merchant page, the authoritative final say on whether the authenticated amount and payee match what is actually being charged.

Preventing Exemption Abuse Through Structuring

A sophisticated attacker who has compromised a card’s credentials might deliberately structure many transactions just below the low-value exemption threshold to avoid ever triggering a challenge. The cumulative counters described earlier in this guide exist specifically to counter this pattern, and the ML risk model is trained to recognise the specific behavioural signature of many small, closely spaced transactions to the same or unfamiliar payees, treating this pattern as a strong signal to deny a requested exemption even when the raw value and counter conditions might otherwise technically permit one.

Securing the Trusted Beneficiary and Recurring Mandate Stores

Because membership on a trusted beneficiary list or an active recurring mandate directly grants a future authentication bypass, both stores require the addition of a new trusted payee or mandate to itself always go through a full, unexempted strong authentication step, and any modification to an existing entry is treated with the same audit rigour as the exemption threshold configuration itself, since these stores are effectively pre-authorized bypass lists and must be defended accordingly.

Protecting Against Social Engineering of the Authentication Step Itself

A well-known and persistent threat, sitting slightly outside the platform’s own architecture but directly affecting the effectiveness of any authentication system, is social engineering, where an attacker tricks a legitimate customer into approving a fraudulent transaction’s authentication challenge themselves, for example by impersonating a bank representative and convincing the customer that approving the prompt is necessary to “protect” their account. While the platform cannot directly prevent a customer from being deceived, dynamic linking mitigates the damage such attacks can cause by ensuring the customer is always shown the specific amount and payee they are actually authenticating, giving an attentive customer a concrete, verifiable detail to notice is wrong, rather than an opaque, generic approval prompt that reveals nothing about what is actually being authorized.

Because this system directly determines the provider’s own measured fraud rate, and that fraud rate in turn determines future exemption thresholds, its observability has a genuine feedback-loop property that most systems do not: bad monitoring here does not just hide problems, it can actively degrade the system’s future performance.

Key Metrics to Track

• Exemption request rate and issuer acceptance rate, tracked per exemption category, to understand how often requested exemptions are actually honoured versus overridden by issuers.
• Checkout friction rate, the proportion of in-scope transactions that ultimately require a live authentication challenge, as the primary measure of how well the system is achieving its friction-minimisation goal.
• Measured fraud rate by value band, feeding directly into which transaction-risk-analysis thresholds the provider currently qualifies for.
• Challenge completion rate and abandonment rate, measuring how many customers who are presented with a live authentication challenge actually complete it versus abandoning the purchase entirely.
• Decision latency, end to end, from transaction submission to final authorization result, broken down by which layer of the funnel resolved the transaction.
• Regulatory reporting completeness, confirming that every in-scope transaction has a complete, auditable decision trail available for compliance reporting.

Logging Practices

Every transaction’s full decision trail, including the scope determination outcome, which exemption category if any was evaluated, the ML risk score at the time, whether an exemption was requested, and the issuer’s response, is logged with a shared correlation identifier, since regulators, internal compliance teams, and fraud investigators all periodically need to reconstruct exactly why a specific transaction was or was not challenged.

Alerting Philosophy

Sudden shifts in exemption acceptance rate by a specific issuer, unexpected spikes in challenge abandonment rate, or a measured fraud rate approaching the boundary of the provider’s currently qualified threshold band are all treated as actionable alerts, since each represents a scenario where either commercial performance or regulatory standing could shift meaningfully within a short window if left unaddressed.

Progressive Delivery for Regulatory-Sensitive Logic

Changes to the regulatory rules engine or exemption thresholds are rolled out through canary deployment with a small percentage of transaction traffic, with automated rollback triggered if key metrics such as exemption acceptance rate or challenge abandonment rate move outside expected bounds, since a subtle bug in this logic can simultaneously create both regulatory exposure and unnecessary commercial friction.

Multi-Region Deployment Within Europe

Given the platform serves customers and merchants across many European jurisdictions, each potentially with slightly different national implementation nuances of the shared regulatory framework, the orchestration and risk analysis services are deployed regionally, with configuration for jurisdiction-specific nuances kept as data rather than code, allowing regional behaviour differences to be managed without requiring a full software deployment for every jurisdictional update.

Infrastructure as Code and Change Auditability

All configuration governing exemption thresholds and rules is defined declaratively and version-controlled, with every change requiring a documented regulatory justification and a second reviewer’s sign-off before deployment, since this configuration is effectively a codified interpretation of legal requirements and must be defensible under audit at any point.

Cloud Provider Considerations

Given the sensitivity of payment authentication data and the specific data residency expectations that can arise under European data protection law, careful attention is paid to which cloud regions host the exemption store, trusted beneficiary store, and transaction logs, generally favouring cloud regions physically located within the European Economic Area for data governed by these requirements.

Database Choice for the Exemption Store

The exemption eligibility store, tracking cumulative per-card counters that directly determine legal compliance, requires strong consistency guarantees for any read-then-write sequence, generally pointing toward a strongly consistent, transactional database rather than an eventually consistent store, since a stale counter read could allow a card to exceed the cumulative exemption limit the regulation requires to be enforced.

Caching Strategy

Regulatory thresholds and merchant-level configuration, which change infrequently, are cached aggressively with short time-to-live refresh windows. Per-card cumulative exemption counters, by contrast, are never served from a stale cache for a write decision, only ever read from the authoritative, strongly consistent store at decision time, since these counters are precisely the kind of state where staleness directly translates into compliance risk.

Load Balancing

Transaction traffic is load balanced across stateless orchestration and risk analysis instances without any need for account-level affinity, since these services do not hold session state themselves; all state that matters for correctness lives in the exemption store and trusted beneficiary store behind them, which is where the meaningful consistency guarantees actually need to be enforced.

Read Replicas for Reporting

Regulatory reporting and internal fraud analytics read from replicas of the transaction log and exemption store, tolerating minor replication lag, while the live decisioning path always reads from the primary, strongly consistent path to guarantee that every exemption decision reflects the true, current counter state.

API Design for the Authentication Decision

The orchestration service exposes a single, well-documented decision endpoint that merchants and internal checkout flows call with full transaction context, returning either a frictionless approval, an exemption-granted approval, or a redirect into a live authentication challenge, with the contract explicitly documenting all three possible outcomes so integrating merchants can build correct handling for each rather than assuming authentication either always or never happens.

POST /v1/sca/decision
Content-Type: application/json
Idempotency-Key: 8f2c3a5e-checkout-attempt-01

{
  "transaction_id": "txn_9f8a1b",
  "amount": { "value": 4290, "currency": "EUR" },
  "payee": { "merchant_id": "mch_kb7", "acquirer_bic": "ACQREUXX" },
  "card": { "issuer_bin_country": "DE", "token": "tok_..." },
  "channel": "web-checkout",
  "customer_present": true,
  "device_signals": { "fingerprint": "df_...", "ip_country": "DE" },
  "trusted_beneficiary": false,
  "recurring_mandate_id": null
}

// Response
{
  "decision": "frictionless" | "exemption_requested" | "step_up_required",
  "exemption_used": "low_value" | "tra" | "trusted" | "recurring" | null,
  "risk_score": 0.083,
  "policy_version": "rules-2026.02",
  "model_version": "risk-v14",
  "next_action_url": "https://acs.issuer.example/challenge/..."
}

Service Boundaries

The scope determination logic, the regulatory rules engine, the ML risk model, and the 3-D Secure integration layer are kept as separate, narrowly scoped services, which allows the regulatory rules engine specifically to be independently audited, versioned, and reasoned about without being entangled with the more experimental, frequently retrained ML component.

Synchronous Versus Asynchronous Boundaries

Everything on the direct path to an authentication decision — scope determination, exemption evaluation, and the issuer round trip — is synchronous, since the customer is actively waiting at checkout. Regulatory reporting, fraud rate recalculation, and ML model retraining all happen asynchronously through the event bus, ensuring that none of these downstream processes can introduce latency into the live checkout path.

Contract Stability With the 3-D Secure Ecosystem

Because the directory server and issuer access control servers are standardised, shared infrastructure operated by card schemes and banks rather than by the platform itself, the integration layer is built against the published protocol specification with strict version negotiation, and any protocol version upgrade is tested extensively against a sandbox environment before being rolled out, since a mismatch here could cause legitimate authentication challenges to fail outright.

Helpful Patterns

Anti-Patterns to Avoid

Best Practices

• Treat the regulatory rules engine as a legal artifact requiring the same review rigour as a contract, not merely as ordinary application code.
• Instrument exemption acceptance rate per issuer from day one, since this is often the earliest, clearest signal that a particular issuer’s own risk tolerance differs from assumptions baked into the risk model.
• Build the customer-facing authentication challenge itself to be as fast and clear as possible, since even a legally necessary challenge can be made meaningfully less frustrating through good design, reducing abandonment even when friction cannot be avoided entirely.
• Regularly recalibrate the ML risk model’s exemption-request threshold against the actual, observed trade-off between issuer rejection rate and measured fraud outcomes, rather than setting it once and leaving it static.
• Maintain a clear, auditable log of every regulatory rule change and its business justification, since compliance audits frequently ask not just what the current rules are but why and when they changed.
• Design the customer-facing messaging around a required authentication step to explain, briefly and clearly, why the step is happening, since customers who understand a security step exists for their own protection are measurably less likely to abandon the purchase than customers who experience it as an unexplained, arbitrary obstacle.
• Build a lightweight internal simulation environment that can exercise every exemption category and every fallback path against realistic synthetic transaction data, so that regression testing of this business-critical decisioning logic does not depend entirely on slow, expensive integration testing against real external issuer sandboxes.

Common Mistakes

• Conflating “legally eligible for an exemption” with “should request an exemption,” when the two are related but genuinely distinct questions this system must answer separately.
• Underestimating the operational complexity of accurately tracking cumulative exemption counters at scale, leading to either compliance gaps or unnecessarily conservative behaviour born from uncertainty about counter accuracy.
• Building the 3-D Secure integration against a single card scheme’s implementation quirks rather than the shared protocol specification, creating brittleness when interacting with other schemes or when a scheme updates its own implementation.
• Neglecting to test the full step-up fallback path as thoroughly as the frictionless exemption path, since this path is exercised less often in everyday testing but is exactly the path a real customer encounters whenever an exemption request is rejected.
• Failing to involve legal and compliance stakeholders early enough in threshold-tuning decisions, treating what is fundamentally a regulated business decision as a purely technical optimisation problem.
• Applying a single, platform-wide risk threshold uniformly across very different merchant categories, when a threshold well tuned for a low-risk digital subscription business may be entirely inappropriate for a higher-risk merchant category such as high-value electronics resale.
• Treating a successful authentication challenge as a permanent, unconditional guarantee of trustworthiness for that card indefinitely, rather than recognising that card compromise can occur at any point after a prior successful, genuine authentication.

Beyond the regulatory and product mechanics, this system rests on genuine distributed-systems and applied statistics foundations worth understanding deeply.

Consistency Requirements and the CAP Theorem

The exemption eligibility store, like the payment ledger in adjacent systems, favours strong consistency over availability during a network partition, because a stale read of a cumulative exemption counter could allow a card to exceed the regulation’s cumulative exemption limits, which is a compliance failure, not merely a minor inconvenience. This is a deliberate trade-off: during a partition that prevents the store from confirming a strongly consistent read or write, the system refuses to grant new exemptions for the affected cards rather than risk operating on stale counter state, falling back instead to requiring full authentication, which is always legally safe regardless of counter accuracy.

Consensus and Replication for Counter Integrity

To keep the exemption counters both durable and consistently observable across replica failures, the store relies on a consensus protocol such as Raft, where a counter update is only acknowledged once durably replicated to a quorum of nodes. This guarantees that once an exemption usage is recorded, it will be consistently visible to the very next transaction on that same card, even across a leader failover, preventing exactly the kind of double-counting or lost-update scenario that could otherwise let an attacker or an innocent retry silently exceed the regulation’s exemption limits.

Concurrency and the Check-Then-Act Problem

Evaluating whether a card has remaining exemption headroom, and then incrementing its usage counter if an exemption is granted, is itself a check-then-act sequence vulnerable to the same class of race condition seen in other financial systems: two near-simultaneous transactions on the same card could each read the same “headroom remaining” value before either commits its increment, jointly exceeding the regulation’s cumulative limit. This is solved the same way it is solved elsewhere in financial systems, by making the check and the increment a single atomic operation against the strongly consistent store, rather than two separate calls.

A related subtlety is that this atomicity requirement extends beyond a single card’s counter in isolation. Some platforms track exemption headroom not just per card but per card-and-merchant-relationship pair, or per card-and-payment-instrument-type combination, meaning a single incoming transaction may need to atomically check and update more than one counter simultaneously. Where this is necessary, the system generally structures the operation as a single transaction against the underlying store that touches all relevant counters together, rather than performing multiple independent atomic operations in sequence, since the latter reintroduces exactly the kind of partial-update race condition atomicity was meant to eliminate in the first place, just at a slightly larger granularity.

Statistical Considerations in Fraud Rate Calculation

The provider’s measured fraud rate, which directly determines its qualifying exemption thresholds, must be calculated over a statistically meaningful rolling window, since too short a window produces a noisy, unstable rate heavily influenced by random short-term fluctuation, while too long a window responds too slowly to genuine, sustained changes in fraud levels. Regulatory guidance typically specifies the exact window and calculation methodology precisely to avoid this ambiguity being exploited or misapplied, and the system’s fraud rate calculation job is built to match that specification exactly rather than approximating it.

Model Drift and Retraining Cadence

Because attacker behaviour and legitimate customer behaviour both evolve over time, the ML risk model is subject to drift, where its historical training data gradually becomes less representative of current transaction patterns. Regular retraining, combined with ongoing monitoring of the model’s calibration against actual outcomes rather than just its raw accuracy, ensures the model’s risk scores remain meaningful inputs to the exemption-request decision rather than gradually becoming stale, overconfident, or systematically biased against certain legitimate transaction patterns that have simply become more common since the model was last trained.

Idempotency Across the Authentication Handoff

The handoff between the platform’s own orchestration service and the external directory server and issuer access control server introduces the same class of network-ambiguity problem seen in other distributed payment systems: a timeout while waiting for an issuer’s response does not necessarily mean the request failed, it may simply mean the response has not yet arrived. Retrying an authentication request without a stable, idempotent reference to the original attempt risks presenting the customer with a duplicate, confusing challenge, or worse, creating two independent authentication sessions for what should be a single transaction. The orchestration service therefore carries a single, stable transaction reference through the entire authentication handoff, and any retry logic is built to recognise and safely resume an in-flight authentication session rather than blindly starting a new one.

Graph-Based Detection of Coordinated Structuring

Beyond scoring individual transactions in isolation, sophisticated structuring attacks — where an attacker splits a large fraudulent purchase across many small transactions or across multiple compromised cards to stay under exemption thresholds — are often more visible when transactions are analysed as a connected graph rather than independently. Shared devices, shared shipping addresses, or shared behavioural fingerprints across superficially unrelated cards and transactions can reveal a coordinated pattern that no single transaction’s individual risk score would surface on its own. The offline batch forensics component of a mature system typically includes graph-based analysis specifically to catch this class of coordinated abuse that pure per-transaction scoring tends to miss.

Designing strong customer authentication for a European payments platform is fundamentally a layered decisioning problem, not a simple binary challenge-or-not switch. The system must first determine whether a transaction is even in scope of the regulation, then evaluate whether a hard, deterministic exemption applies, then weigh whether a discretionary, risk-based exemption is both legally eligible and commercially wise to request, and finally gracefully fall back to a genuine authentication challenge whenever the issuing bank, which always holds final authority, decides one is warranted.

Getting this right requires combining an auditable, legally precise rules engine with a continuously improving statistical risk model, backed by a strongly consistent store for the stateful counters the regulation requires to be tracked accurately, and a resilient integration layer that treats any uncertainty or external failure as a reason to fail toward safety rather than toward silent bypass. The organisations that do this well treat friction reduction not as a one-time technical project but as a continuous feedback loop, where a genuinely low, well-measured fraud rate directly and compoundingly earns a wider exemption envelope for future transactions.

Ultimately, the best systems in this space succeed by treating regulation and user experience not as opposing forces to be traded off once and forgotten, but as two inputs to the same continuously optimised decision, made fresh, correctly, and quickly for every single transaction that flows through the platform.

For engineers newly approaching this domain, the most durable mental model is this: every transaction deserves the least friction that remains fully compliant and appropriately safe, and discovering exactly where that boundary sits, for each transaction, each merchant, and each moment in time, is not a problem solved once during initial design, but an ongoing engineering and data discipline that pays continuous dividends the better it is executed.

The teams that internalise this mindset tend to look back on strong customer authentication not as a burdensome mandate bolted onto an existing checkout flow, but as one of the clearer examples in modern payments engineering of how a well-designed system can genuinely satisfy a strict regulatory requirement and a demanding commercial goal at the same time, provided the underlying architecture is built with enough precision, resilience, and continuous feedback to keep both promises honestly.