Online authentication

what is 3ds and why it matters 3d secure ( ) is a protocol that allows a cardholder to authenticate an online transaction cross river supports the latest evm 3ds standard the merchant (3ds requestor) collects around 150+ data points from the cardholder's transaction environment the merchant sends this data through the card network to cross river's access control server (acs) for risk scoring the acs evaluates the risk of each transaction based on the rules configured key flows frictionless flow the issuer's acs approves authentication silently using risk signals (device, location, behavior) this flow requires no cardholder action this is the preferred path as it maximizes approval rates challenge flow issuer requests explicit cardholder verification (otp, push app notification) when the risk score is elevated this adds friction but protects high risk transactions liability shift when a 3ds authenticated transaction is later disputed as fraudulent, liability moves from the merchant to the card issuer this applies specifically to fraud related chargebacks such as visa (other fraud – card absent) and mastercard (no cardholder authorization) the liability shift does not exclude non fraud related disputes such as service disputes you need to check your agreement with cross river to determine ultimate responsibility for fraud on a given card program when 3ds is required regional requirements europe & uk (mandatory) under psd2 (payment services directive 2) regulations, strong customer authentication (sca) is required for most online transactions in the european economic area and uk 3ds 2 0 is the primary method for satisfying sca requirements exemptions exist for low value transactions (under €30) trusted beneficiaries low risk transactions (based on issuer risk analysis) corporate payments united states (optional but recommended) 3ds is not legally mandated in the us however, many merchants choose to implement it for liability shift protection successfully authenticated transactions shift fraud liability from merchant to issuer reduced chargebacks lower fraud related chargeback rates international consistency simplified global payment processing large transactions added security for high value purchases other regions canada optional, increasingly adopted australia optional, recommended for e commerce asia pacific requirements vary by country (india mandates for certain transaction types) why card programs need 3ds merchant driven requirement when a merchant implementing 3ds processes a transaction with a partner's card, the card program must support the authentication request without an acs (access control server), cards would be declined at 3ds enabled merchants or marked as "not enrolled," which creates poor cardholder experience may result in transaction declines limits where cardholders can shop (especially internationally) increases merchant concerns about fraud risk scenarios without 3ds scenario 1 card not enrolled (no acs at all) when the merchant's 3ds server queries the directory server (ds) and the partner's card program has no acs registered for a bin range, the ds responds indicating the card is not enrolled in 3ds at this point the merchant must decide whether to proceed without authentication no liability shift occurs (merchant retains fraud risk) some merchants may decline the transaction entirely international merchants (especially in europe) may reject the payment scenario 2 acs temporarily unavailable if the card program has an acs but it's experiencing downtime the ds responds with a technical error the merchant typically cannot proceed with authentication may result in transaction decline or fallback to non authenticated flow creates negative cardholder experience best practice card issuers should implement 3ds even when not legally required to support cardholders shopping at 3ds enabled merchants enable global e commerce acceptance provide fraud protection tools§ offer liability shift benefits to reduce disputes 3ds as a fraud prevention tool 3ds verifies that the person initiating the transaction is a legitimate cardholder the data the issuer's acs receives for both approved and declined transactions helps identify risk use this data to spot patterns and refine risk models apply these insights to make stronger authorization decisions over time key considerations while not mandatory in the us, 3ds is recommended for issuers without a 3ds solution, liability for fraudulent transactions moves entirely to the issuer better authorization decisions use 3ds outcomes and data to improve your authorization logic merchants start the process in the us, merchants 3ds adoption is optional in the eu and other regions, nearly all online transactions use 3ds to satisfy the strong customer authentication requirement under psd2 without it, issuers and merchants risk non compliance