Cards

The payment credential that connects people, merchants, banks, and networks

A customer taps a phone at a supermarket, a business traveller pays for a hotel with a corporate card, and a small company creates a single-use virtual card for a supplier invoice. These experiences feel simple because the complicated work has been hidden behind a familiar credential.

A card is not money stored inside a piece of plastic. It is a physical or digital credential that allows a cardholder to request a payment, cash withdrawal, refund, or other supported transaction against an underlying funding arrangement. That funding arrangement may be a deposit account, a credit line, a prepaid ledger balance, or another account structure maintained by an issuer or programme provider.

The card ecosystem is powerful because it joins customer experience, real-time decisioning, cryptography, merchant acceptance, clearing, settlement, accounting, fraud controls, disputes, and regulation into one operating model. The customer sees a tap or click. The bank sees a sequence of messages, controls, balances, liabilities, and financial entries that must remain consistent from authorisation through final settlement.

This chapter explains cards as one connected banking system. It distinguishes the card credential from the account behind it, separates authentication from authorisation, shows how issuer and acquirer responsibilities differ, and explains why an approved transaction is not yet the same as a settled transaction.

Learning objectives

By the end of this chapter, you will be able to:

• Explain what a card is and how it connects to an underlying funding source.
• Distinguish debit, credit, charge, prepaid, virtual, commercial, and tokenised cards.
• Identify the roles of the cardholder, merchant, issuer, acquirer, processor, gateway, network, and settlement bank.
• Trace a transaction through authentication, authorisation, capture, clearing, settlement, posting, and reconciliation.
• Explain available balance, ledger balance, authorisation holds, shadow balances, and posted transactions.
• Describe EMV chip, contactless, magnetic stripe, card verification values, PINs, cryptograms, tokenisation, and digital wallets.
• Explain the purpose and limitations of 3-D Secure and Strong Customer Authentication.
• Compare card-present, card-not-present, recurring, offline, stand-in, ATM, refund, reversal, and cash transactions.
• Understand interchange, scheme fees, merchant service charges, interest, and card-related revenue.
• Describe fraud controls, card status management, disputes, chargebacks, and operational support.
• Recognise architecture choices, reconciliation requirements, testing needs, and common implementation mistakes.

What a card actually is

A card is a payment credential issued under the rules of a card network or domestic card scheme. It identifies an issuer relationship and points to an account or balance arrangement that can support transactions.

The physical card may carry a chip, magnetic stripe, cardholder name, expiry date, network branding, and a printed or embossed Primary Account Number. A digital card may exist only in an application or wallet. A tokenised card may present a payment token instead of the underlying PAN during a transaction.

The important distinction is between the credential and the money behind it.

A common design mistake is to treat the card number as the bank account number. They are related but not necessarily identical. One account may have several cards, one customer may hold cards linked to different accounts, and commercial programmes may create many employee cards under one corporate account structure.

PAN, IIN or BIN, and account ranges

The PAN is structured according to network and industry rules. The leading digits identify an Issuer Identification Number, commonly still called a BIN in banking operations. Modern card programmes increasingly work with eight-digit IIN or BIN ranges, although six-digit terminology remains widespread in legacy systems and business language.

The IIN or BIN range is allocated, sponsored, or managed under network rules. The issuer or sponsor then configures product and account ranges within the permitted allocation. A bank cannot simply invent a routable range and expect the network to recognise it.

The final PAN digit is normally a check digit calculated using the Luhn algorithm. It helps detect many data-entry errors, but it is not a security control and does not prove that a card is genuine or active.

The card ecosystem

Most open-loop card transactions involve four principal parties:

• The cardholder uses the card.
• The merchant accepts the transaction.
• The issuer provides the cardholder relationship and is accountable for the issuing side.
• The acquirer provides the merchant relationship and is accountable for the acquiring side.

A card network connects the issuer and acquirer, sets operating rules, routes messages, manages clearing arrangements, calculates obligations, and coordinates settlement processes. The final movement of funds may occur through designated settlement banks, central-bank accounts, correspondent arrangements, or other approved infrastructure.

Additional parties may include:

The words issuer, processor, programme manager, sponsor bank, and fintech should never be treated as interchangeable. A processor may execute authorisations, but the licensed issuer remains accountable for defined scheme and regulatory obligations. A programme manager may own the brand and customer experience, while a sponsor bank holds the network membership and regulatory responsibility. The exact allocation must be confirmed from contracts, law, scheme rules, and the operating model.

Open-loop and three-party models

Visa and Mastercard are common examples of open-loop networks in which many issuers and acquirers participate. American Express and Discover have historically operated more integrated models, but real market structures vary. They may issue directly, work with partner issuers, license acceptance, or use different arrangements by country and product.

It is therefore safer to think in terms of functions rather than assuming that every network has one permanent structure. Ask who issues, who acquires, who routes, who calculates financial obligations, who moves settlement funds, and who owns the customer and merchant contracts.

Debit cards

A debit card normally draws against funds available in a linked deposit account. Authorisation commonly considers available funds, configured overdraft, card limits, risk controls, pending authorisation holds, account status, and channel rules.

The simple statement that “the balance is the limit” is incomplete. Banks may maintain several balances:

Delayed presentment, tips, transport transactions, offline acceptance, stand-in processing, and duplicate or missing reversals can cause the final posted amount to differ from the amount initially reserved.

Credit cards

A credit card provides access to a credit line. An authorisation reduces available credit or creates a pending exposure. Clearing later produces the financial transaction that is posted to the card account.

A credit card combines a payment product with lending. The issuer must manage credit assessment, limit setting, statements, minimum payments, interest, fees, delinquency, collections, consumer protection, and responsible lending requirements.

The credit limit is not the same as the amount that should always be approved. Available credit may be reduced by pending transactions, cash limits, instalment plans, risk rules, delinquency, temporary blocks, or product-specific controls.

Charge cards

A charge card generally requires the statement balance to be paid in full at the end of the billing period. Some products advertise no preset spending limit. This does not mean unlimited spending. The issuer may calculate dynamic purchasing power using payment history, exposure, customer profile, recent activity, risk signals, and internal limits that are not displayed as one fixed number.

Prepaid cards

A prepaid card is normally linked to a prefunded or stored-value balance maintained in an issuer, processor, or programme ledger. The card is usually the access credential; the monetary value is not physically stored on the plastic card.

Closed-loop or offline electronic-purse designs may operate differently, but they should not be treated as the standard model for modern network-branded prepaid cards.

Prepaid programmes require careful design around safeguarding, customer identification, loading limits, redemption, expiry, inactivity, fees, negative balances, breakage, programme funding, and regulatory classification.

Virtual cards

A virtual card is issued without requiring a physical card. It may be reusable, single-use, merchant-locked, amount-limited, date-limited, or created for a particular invoice or supplier.

Virtual cards are especially useful in commercial payments because they can combine payment with policy control. A company can generate a credential that works only for one merchant category, one supplier, one amount, or one period. This reduces misuse and improves automated reconciliation when the payment reference is linked to the purchase order or invoice.

Digital wallets and tokenisation

A mobile wallet normally stores or uses a payment token rather than exposing the underlying PAN to the merchant. Tokenisation reduces the value of stolen merchant data because the token may be restricted by device, wallet, token requestor, merchant, domain, or transaction context.

Not all tokens have the same scope:

During authorisation, token resolution occurs within the token service and network processing chain. The exact message flow varies by network, token service provider, processor, and issuer implementation. The issuer may receive token-related data, token assurance information, device or requestor indicators, and the underlying account reference needed for decisioning.

Tokenisation does not remove every risk. Fraud can still occur through compromised account provisioning, social engineering, merchant account takeover, device compromise, or misuse of a legitimately provisioned token. Token lifecycle controls such as suspend, resume, delete, reissue, and account updater events are therefore essential.

Card security values and cryptograms

Different security values serve different purposes.

• Magnetic-stripe verification values help detect copied or fabricated stripe data.
• Printed card-not-present values such as CVV2 or CVC2 support ecommerce and mail-order verification.
• EMV chip cryptograms are transaction-specific values generated using chip data, keys, counters, and transaction context.
• Dynamic contactless data helps protect tap transactions from simple replay.
• PIN verification supports cardholder verification but does not itself prove that the whole transaction is legitimate.

Terminology differs by network. CVV and CVC are related concepts but should not be treated as one universal field name. Chip cryptograms are also different from the static values printed on a card.

EMV chip and contactless

EMV chip technology materially reduced counterfeit fraud in markets where chip acceptance and correct processing were implemented. It did not eliminate fraud. Criminal activity shifted toward card-not-present fraud, social engineering, account takeover, fallback abuse, lost and stolen cards, and compromised digital channels.

A chip transaction involves application selection, terminal risk management, cardholder verification, cryptogram generation, issuer decisioning, and terminal action analysis. The exact sequence depends on contact, contactless, online, offline, and network rules.

Contactless transactions use near-field communication and can be performed by a physical card, phone, watch, or another supported device. Low-value transactions may be accepted with simplified cardholder verification depending on local rules and cumulative limits. Higher-risk transactions may require online PIN, device authentication, or another verification method.

Authentication, cardholder verification, and authorisation

These terms are related but different.

Authentication seeks evidence that the person or device is entitled to use the credential. Cardholder verification is the card acceptance process used to verify the person, such as PIN, signature, device biometric, or no verification under permitted rules. Authorisation is the issuer-side or delegated decision about whether the transaction should proceed.

A transaction can be strongly authenticated and still be declined because of insufficient funds, fraud controls, account status, limits, merchant restrictions, or technical rules. A transaction can also be approved without proving that it will later clear and settle exactly as authorised.

3-D Secure

EMV 3-D Secure supports authentication for card-not-present transactions. It allows merchant, acquirer, network, directory, access-control, issuer, and risk information to be exchanged so that a transaction may proceed frictionlessly or require a challenge.

3-D Secure can improve fraud control and may influence liability allocation under applicable rules. It does not guarantee approval, eliminate fraud, or replace issuer authorisation. The issuer may still decline an authenticated transaction, and liability outcomes depend on the exact version, exemption, data quality, authentication result, market, and scheme rules.

The transaction lifecycle

1. Initiation

The cardholder presents a card, wallet, token, or stored credential. The merchant system creates a transaction using amount, currency, merchant identifiers, terminal or channel data, and card information.

2. Authentication and cardholder verification

The channel performs the relevant verification. This may involve EMV, PIN, wallet biometric, 3-D Secure, CVV2, or another method. The result becomes an input into risk and liability treatment.

3. Authorisation

The merchant sends an authorisation request through the acquirer and network to the issuer or an authorised stand-in processor. The decision may consider:

• Card status and expiry.
• Account status.
• Available funds or available credit.
• Product and transaction limits.
• Merchant category and country controls.
• Fraud score and behavioural signals.
• Authentication and cryptogram results.
• Token assurance data.
• Velocity and recent transaction history.
• Regulatory or sanctions-related restrictions where applicable.

The response may approve, decline, partially approve, refer, or return another supported outcome. The response code and approval code describe the authorisation decision. They are not proof that final financial settlement has occurred.

4. Hold or pending entry

For many products, an approved authorisation creates a hold or pending amount. The customer may see reduced available funds even though the final transaction has not yet been posted.

5. Capture

The merchant confirms that the transaction should be submitted for clearing. Some environments combine authorisation and capture. Others separate them, especially hotels, car rental, ecommerce fulfilment, tipping, and delayed-delivery businesses.

6. Clearing

The acquirer submits financial transaction data under network rules. Clearing validates and exchanges the transaction information needed to calculate obligations between participants. The clearing amount may differ from the authorisation amount because of tips, completion, partial shipment, foreign exchange, incremental authorisations, or permitted adjustments.

7. Settlement

The network or clearing arrangement calculates participant obligations. The actual movement of settlement funds occurs through the applicable settlement infrastructure and accounts.

8. Posting

The issuer or its processor posts the financial transaction to the card account, deposit account, credit ledger, or prepaid ledger. Posting may happen in real time, near real time, intraday cycles, or batch depending on the market and architecture.

9. Reconciliation

Operations and finance prove that authorisations, clearing, settlement, posting, fees, interchange, refunds, reversals, and general-ledger entries are complete and consistent.

Real time and batch are not opposites

Card systems usually combine event-driven and scheduled processing.

A modern architecture should not assume that every financial event waits until end of day. It should support the cadence required by the network, product, ledger, customer experience, and regulatory environment.

Reversals, voids, refunds, and corrections

These terms should be separated carefully.

Using “reversal” for all of these events leads to broken ledgers, incorrect customer balances, and poor reconciliation.

Offline and stand-in processing

An offline transaction is accepted without a live issuer response under configured card, terminal, and network rules. Stand-in processing occurs when a network or processor makes a decision because the issuer host is unavailable or cannot respond in time.

Both models create exposure. The decision may use limits, card status data, risk parameters, historical behaviour, and network controls, but it cannot always access the issuer’s latest balance or fraud state. Institutions therefore define stand-in limits, excluded merchant categories, country restrictions, cumulative exposure, and post-event monitoring.

Card status management

Card status must be reflected consistently across the card management platform, authorisation host, processor, wallet tokens, customer channels, fraud tools, and relevant network services.

Modern online authorisation normally relies primarily on issuer or processor status controls. Network exception files and offline controls may also be used, but there is no single universal global hotlist mechanism that guarantees every offline acceptance point instantly knows a card’s latest status.

Card management system and surrounding platforms

The card management system is commonly the system of record for card lifecycle and product data, but responsibilities vary by architecture.

A complete estate may include:

• Customer and identity platform.
• Product configuration service.
• Card management system.
• Authorisation host.
• Network switch.
• Limits engine.
• Fraud decision engine.
• Token management platform.
• Billing and statements platform.
• Credit ledger or deposit core.
• Posting engine.
• Dispute and chargeback platform.
• Rewards engine.
• Notification service.
• General ledger and finance systems.
• Data platform and regulatory reporting.

The CMS may receive clearing data, but posting can be performed by a separate processor, posting engine, ledger, or core banking platform. Statements may also be produced by a dedicated billing system. Architecture documentation must describe actual ownership rather than assuming one product performs every card function.

Economics of cards

Card economics vary by market, network, product, regulation, transaction type, and commercial contract.

The issuer may earn interchange, interest, annual fees, cash fees, foreign-exchange margin, instalment income, and partnership revenue. The acquirer may earn merchant service charges, gateway or terminal fees, processing fees, foreign-exchange income, and value-added service fees. Networks charge scheme, processing, assessment, token, dispute, and other fees.

Interchange is commonly paid from the acquiring side to the issuing side through the clearing and settlement arrangement, but rates may be regulated, capped, bilaterally agreed, domestically determined, or dependent on product and transaction qualification.

A merchant’s total price may include:

• Interchange.
• Scheme fees.
• Acquirer margin.
• Processor and gateway charges.
• Terminal or device rental.
• Fraud and 3-D Secure services.
• Chargeback and exception fees.
• Cross-border and currency charges.

An apparently profitable portfolio can become unprofitable when fraud, rewards, credit losses, processing, disputes, funding, customer support, and compliance costs are included.

Fraud and risk

Card risk exists across the whole lifecycle:

• Application fraud during onboarding.
• Account takeover.
• Lost and stolen card use.
• Counterfeit or fallback fraud.
• Card-not-present fraud.
• Card testing.
• Merchant compromise.
• Wallet provisioning fraud.
• Friendly fraud and dispute abuse.
• Insider misuse.
• Processor, configuration, or operational errors.

Fraud models should not operate as isolated black boxes. Their decisions must align with customer authentication, limits, card status, merchant risk, device information, token data, dispute outcomes, and case management.

A good control strategy balances fraud loss against false declines. Declining every unusual transaction would reduce some fraud but destroy customer trust and card usage. The goal is controlled acceptance, not maximum rejection.

Disputes and chargebacks

A dispute begins when a cardholder questions a transaction. The issuer investigates and decides whether the case qualifies for recovery under network or legal rules. A chargeback is a formal financial claim through the network process.

The process may include inquiry, retrieval, first chargeback, representment, pre-arbitration, arbitration, compliance, or other scheme-specific stages. Exact reason codes, evidence, time limits, and liability rules change and must be checked against the current official rulebook.

3-D Secure, EMV, tokenisation, authorisation data, merchant evidence, delivery proof, recurring-payment disclosures, cancellation records, and transaction identifiers can affect the outcome. None should be described as an automatic guarantee.

PCI DSS and data protection

PCI DSS applies to environments that store, process, or transmit cardholder data, as well as connected systems that can affect security. Scope must be assessed using the current standard and validated under the applicable merchant or service-provider requirements.

Strong design principles include:

• Minimise PAN storage.
• Tokenise early.
• Encrypt data in transit and at rest where required.
• Segment the cardholder-data environment.
• Use least privilege and strong authentication.
• Protect cryptographic keys in approved HSM processes.
• Log and monitor administrative and payment activity.
• Maintain secure software development and vulnerability management.
• Never store prohibited sensitive authentication data after authorisation.

Compliance is not the same as security. A compliant environment can still be attacked if controls are weakly operated, and a secure design still requires evidence, governance, and periodic validation.

Reconciliation and financial control

Card reconciliation should connect the full chain:

• Merchant or channel transaction.
• Authorisation request and response.
• Reversal or timeout handling.
• Clearing record.
• Network settlement position.
• Issuer or acquirer posting.
• Fees and interchange.
• Customer or merchant account entry.
• General-ledger posting.
• Refund, dispute, and adjustment events.

Important reconciliation keys may include PAN token or masked reference, system trace audit number, retrieval reference, authorisation code, network reference, merchant identifier, terminal identifier, transaction timestamp, amount, currency, clearing sequence, settlement date, and internal event identifier.

No single identifier is reliable in every flow. Reconciliation should use controlled matching hierarchies, tolerances, duplicate detection, ageing, ownership, and auditable resolution.

Architecture and event processing

A modern card platform may use APIs and event streams around established card processors and network interfaces. Kafka or another event platform can distribute events such as:

• Card created or activated.
• Card status changed.
• Token provisioned or suspended.
• Authorisation approved or declined.
• Reversal received.
• Clearing transaction posted.
• Settlement completed.
• Dispute opened.
• Fraud case created.

Event-driven architecture does not remove the need for transaction integrity. Events must be idempotent, ordered where required, traceable, replayable under control, protected from sensitive-data leakage, and reconciled against systems of record.

Non-functional requirements

Card services require high availability, low latency, controlled degradation, strong security, and recoverable financial processing.

Key requirements include:

• Predictable authorisation latency.
• 24x7x365 availability for customer-facing controls and transactions.
• Defined stand-in and failover behaviour.
• Idempotency for retries and duplicate messages.
• Auditability of every decision and status change.
• Recovery without duplicate financial posting.
• Data retention aligned with law, scheme rules, and dispute windows.
• Capacity for peak events and fraud attacks.
• Monitoring by product, network, processor, country, merchant category, and response code.
• Tested business continuity and disaster recovery.

Testing a card platform

Testing must go beyond happy-path approvals.

Important scenarios include:

• Approved authorisation with successful clearing.
• Decline for funds, credit, status, limits, risk, and invalid data.
• Timeout followed by late response.
• Duplicate authorisation.
• Reversal before and after timeout.
• Clearing without matching authorisation.
• Amount difference between authorisation and clearing.
• Partial approval and partial capture.
• Offline and stand-in transactions.
• Tokenised and PAN-based transactions.
• Contact, contactless, ecommerce, recurring, and ATM flows.
• Lost, stolen, expired, frozen, compromised, and reissued cards.
• Refunds, chargebacks, and representment.
• Currency conversion and cross-border fees.
• Posting failure and controlled replay.
• Network file duplication or missing sequence.
• Reconciliation breaks and ageing.

The expected result must cover customer balance, available funds, card status, network response, financial posting, general ledger, notification, fraud event, and reconciliation—not only the response code.

Common implementation mistakes

The most common mistakes are conceptual rather than technical:

• Treating approval as final payment.
• Treating PAN as the customer account number.
• Assuming all processing is end-of-day batch.
• Using one word, reversal, for several different financial events.
• Assuming a mobile-wallet token is always merchant-specific.
• Assuming tokenisation eliminates fraud.
• Treating no preset spending limit as unlimited credit.
• Treating prepaid value as physically stored on the card.
• Assuming every expired card must be hotlisted.
• Assuming one universal network hotlist protects every transaction.
• Assigning clearing, posting, billing, and ledger ownership to the CMS without checking the real architecture.
• Using an ISO 8583 field example as though every network profile is identical.
• Ignoring settlement banks, funding accounts, fees, and general-ledger reconciliation.
• Testing only approval and decline instead of the full financial lifecycle.

Practical example

A customer uses a tokenised debit card in a mobile wallet to pay EUR 80 at a hotel restaurant.

The wallet presents a device payment token and dynamic transaction data. The terminal sends the request to the acquirer, which routes it through the network. The token service resolves the token within the network processing chain and provides the information required for issuer decisioning. The issuer checks card and token status, available funds, limits, fraud signals, merchant category, authentication data, and account status.

The issuer approves and creates an EUR 80 hold. The customer’s available balance falls, but the ledger balance may remain unchanged until posting. The merchant later captures EUR 92 after adding an authorised tip. The clearing record arrives for EUR 92. The issuer releases or adjusts the original hold and posts EUR 92 according to its processing design. The network calculates settlement obligations, and funds move through the applicable settlement arrangement.

Reconciliation links the original authorisation, the adjusted clearing amount, the posting, the network settlement entry, fees, and the general-ledger records. If the EUR 80 hold is not released correctly, the customer may temporarily lose access to EUR 172 even though only EUR 92 was spent. This is why card quality depends on lifecycle control, not merely on producing an approval response.

Functional card product model

A card platform is easier to understand when the card is treated as a product instance with a precise relationship to other banking objects. The card is the credential. The customer is the person or organisation allowed to use it. The account is the funding or repayment arrangement. The product defines what the credential can do. The programme defines the operating model, network relationship, BIN range, economics, compliance duties, and servicing rules. When these boundaries are blurred, card implementations become difficult to change because every downstream system starts inventing its own meaning for the same object.

A functional card record normally carries the card identifier, masked PAN or token reference, product code, card type, issuer, network, BIN or account range, cardholder, customer, linked account, billing account, status, status reason, issue date, activation date, expiry date, embossing or display name, delivery method, replacement relationship, digital-wallet eligibility, contactless eligibility, cash access flag, ecommerce flag, international usage flag, recurring-payment flag, and velocity profile. PAN storage requires applicable PCI protection and minimisation. Sensitive authentication data such as card verification codes, full track data and PIN/PIN blocks must not be retained after authorisation in merchant/acquiring environments, even encrypted. A secure vault does not create an exception. Issuers and issuing-service providers have a narrowly scoped exception only for a legitimate issuing business need, subject to applicable safeguards; see PCI SSC FAQ 1280. Protect issuer keys and permitted cryptographic operations through the applicable HSM, key-management and access-control requirements; do not log secret values in CRM, cases or application telemetry.

The product configuration tells the card platform which features are available. A consumer debit card may allow ATM withdrawals, domestic point-of-sale purchases, contactless, online purchases, wallet provisioning, balance inquiry, and card controls in the mobile app. A consumer credit card may add revolving credit, billing-cycle rules, cash advance treatment, minimum payment rules, rewards, instalment conversion, and promotional APR offers. A business debit card may allow employee cards, merchant-category restrictions, daily spend limits, delegated administration, expense data, and account hierarchy. A commercial credit card may add company liability, individual liability, lodge accounts, central billing, statement files, enhanced data capture, and accounting-system integrations.

The bank should distinguish between card product, card account, plastic or credential, and token. A card product is the commercial offer. A card account is the financial relationship that accumulates transactions, fees, interest, rewards, or repayment obligations. A physical card is one credential attached to that account. A wallet token is another credential, often device-specific and with its own status. A virtual card is a credential that may be limited by merchant, amount, date, or purpose. If the bank does not model these separately, simple customer requests become risky. Closing a lost plastic card should not necessarily close the account. Suspending a wallet token should not necessarily block the physical card. Reissuing a card should preserve statement history, rewards, disputes, and repayment arrangements.

A useful card domain model includes a parent-child relationship between original card and replacement card. Replacement reasons include lost, stolen, damaged, compromised, expired, product upgrade, name change, merchant compromise, fraud strategy, and operational correction. Each reason has different effects. A lost or stolen replacement usually blocks the old credential immediately or after a very short grace window. An expiry reissue may allow the old card until expiry while the new card is activated. A product upgrade may preserve the PAN or issue a new PAN depending on network rules, BIN strategy, token behaviour, and account updater support. The replacement record must let servicing teams explain exactly which credential is active and which transactions are expected to continue.

Cards also need explicit fulfilment and activation states. A newly created card may be requested, approved, personalised, produced, dispatched, delivered, activated, or failed. Digital issuance may compress this lifecycle to seconds, but it still needs equivalent evidence. Operations should know whether a card failed because embossing data was invalid, a fulfilment vendor rejected the file, postal delivery failed, a customer failed identity step-up, or wallet provisioning was declined. These states matter for customer promises, fraud exposure, complaints, vendor service-level agreements, and cost control.

Card controls and limits

Card controls are the functional bridge between customer preference, bank risk policy, and real-time authorization. They decide what the card is allowed to do before an authorization is approved. Good card controls are not a decorative mobile-app feature. They are part of the bank's risk and customer-protection architecture, and they must be enforceable consistently across physical card, virtual card, wallet token, ATM, POS, ecommerce, recurring payment, and mail-order or telephone-order channels.

Common controls include status control, transaction-type control, channel control, geography control, merchant-category control, velocity control, amount control, cash-access control, contactless control, ecommerce control, wallet-token control, recurring-payment control, and international-use control. The platform should know which controls are customer-managed, bank-managed, employer-managed, relationship-manager-managed, fraud-managed, or regulatorily mandated. A customer may be allowed to turn ecommerce on and off. A business administrator may be allowed to cap an employee card. Fraud operations may block a card after confirmed compromise. A regulatorily required freeze, lien, sanction hit, deceased status, or court order should not be overridden by a customer toggle.

The authorization engine must evaluate controls in a predictable order. Hard legal restrictions and sanctions blocks should fire before customer preferences. Closed, blocked, stolen, or fraud statuses should fire before spend limits. Merchant category restrictions should be checked before available balance if the bank wants decline reasons to be accurate. Velocity rules should use authorization history, including reversals and partial approvals, in a way that avoids both false availability and customer confusion. If multiple rules decline a transaction, the platform should store all failed checks internally but present the most appropriate customer-facing reason.

Controls also need date and time semantics. A daily limit can mean calendar day in the customer's time zone, processing day in the bank's time zone, network settlement day, rolling 24-hour window, or business-defined cycle. For a travel card, geography rules may be effective from the start of a trip date in one time zone and end after return. For a commercial virtual card, a supplier payment may be valid only between invoice approval and expiry. Ambiguous time semantics create unnecessary declines and disputes, especially for cross-border transactions.

A bank should provide explainability for every control decision. When a transaction is declined, servicing teams need to see the attempted amount, merchant, MCC, channel, country, terminal capability, card status, token status, account status, available balance, relevant limits, velocity counters, and matched rule. A generic decline code is not enough. Without explainability, customers receive vague answers, fraud teams cannot tune rules, and product teams cannot know whether controls are protecting the bank or damaging legitimate usage.

Authorization decisioning in functional detail

Authorization is the moment when the card platform decides whether the bank will approve, decline, partially approve, refer, or stand in for a transaction request. The customer experiences this as a yes or no at checkout. The bank experiences it as a real-time decision involving identity, credential status, account state, risk policy, limits, available funds or credit, network rules, merchant data, cryptographic validation, and operational resilience. A card chapter that stops at "authorization checks balance" misses most of the work.

A typical authorization request includes message type, processing code, amount, currency, transmission date and time, system trace audit number, local transaction time, merchant type, acquiring institution, retrieval reference number, terminal ID, merchant ID, merchant name and location, card data entry mode, POS condition code, cardholder verification method, chip or contactless data, ecommerce indicators, token data, 3-D Secure data, recurring-payment indicators, cash-back amount, replacement amount, and network-specific private fields. The issuer host may not use every field for every transaction, but it should preserve enough of the request to explain the decision later.

The decision sequence usually starts with message validation. The platform checks whether the message can be parsed, whether mandatory fields are present, whether the card or token can be identified, whether the transaction type is supported, and whether cryptographic validation passes where required. It then checks card and account status. A closed card, stolen card, blocked token, charged-off credit account, dormant deposit account, restricted business account, or sanctions-blocked customer may require immediate decline. Next come product and customer controls, then fraud and risk rules, then balance or credit availability, then posting of an authorization hold or memo record.

Available funds are not simply ledger balance. For a debit card, available balance may start with current balance, subtract existing holds, subtract unavailable deposits, respect overdraft limits, account blocks, minimum-balance rules, sweep arrangements, cheque holds, loan offsets, or relationship-level liquidity rules. For a credit card, available credit may start with credit limit, subtract outstanding balance, subtract authorizations, add payments subject to hold rules, consider temporary credit-line increases, overlimit strategy, cash-advance limits, promotional balances, delinquency status, and exposure across related accounts. For a prepaid card, availability may include stored-value ledger, pending loads, programme reserve rules, and negative-balance recovery controls.

Authorization holds need their own lifecycle. A hold is not the same as final posting. It reserves funds or credit for a probable future clearing item. The hold may be exact, estimated, incremental, partially reversed, fully reversed, expired, matched to clearing, force-posted, or manually adjusted. Hotels, car rental firms, fuel pumps, tips, transit, and delayed-clearing merchants often create authorization-clearing differences. The platform should support tolerance rules and matching logic rather than treating every mismatch as an exception. It should also disclose pending entries to customers in language that avoids confusing pending holds with settled charges.

Decline reasons are both technical and human. Internally, the platform may store precise codes such as invalid CVV, expired card, insufficient funds, stolen card, restricted card, suspected fraud, exceeded PIN tries, MCC blocked, international disabled, token suspended, cash advance unavailable, account closed, issuer unavailable, or stand-in declined. Externally, the bank may need gentler and safer messages. A suspected-fraud decline should not reveal the rule that fired. A sanctions or law-enforcement block may require controlled wording. An insufficient-funds decline should be clear enough for the customer to fix the problem. The implementation should separate internal reason, network response code, customer message, servicing guidance, and regulatory notice where applicable.

Partial approval is an important functional choice. Some networks and merchants support approving less than the requested amount, especially for prepaid, debit, or gift-card scenarios. Partial approval can improve customer experience but creates operational complexity. The merchant must be able to handle split tender. The customer must understand why only part of the transaction was approved. Holds, clearing, reversal, and receipt logic must reflect the approved amount, not the requested amount. If the product does not support partial approval, the platform should decline cleanly.

Stand-in processing is another functional choice. When the issuer host is unavailable, a network or processor may approve or decline based on preconfigured rules. Stand-in can protect customer experience but creates exposure because the network may not know the latest balance, fraud status, or customer controls. The bank must define stand-in limits, eligible products, excluded transaction types, fallback status files, negative files, velocity assumptions, offline floor limits, and post-recovery reconciliation. After recovery, stand-in approvals must be imported, matched, posted, and analysed. The bank should know how much financial exposure it accepted while it was offline.

Posting, holds, clearing, and customer balances

Card transactions create customer confusion when the bank cannot explain the difference between authorization, pending balance, posted transaction, available balance, statement balance, and settlement. A robust implementation treats these as distinct but connected states. The card platform, core ledger, customer channels, statements, finance systems, and dispute platform must agree on what each state means.

For debit cards, the initial authorization normally creates a hold on the deposit account or a card subledger linked to the deposit account. The customer may see a pending transaction and reduced available balance. When clearing arrives, the platform matches the clearing item to the authorization and converts the hold into a posted debit. If clearing is lower than the authorization, the remaining hold is released. If clearing is higher within permitted tolerance, the additional amount may post. If no clearing arrives, the hold expires according to product, merchant, and network rules. If clearing arrives with no authorization, the platform may force post, reject, investigate, or route to exception handling depending on liability and scheme rules.

For credit cards, authorization reduces available credit but may not immediately change statement balance. Clearing posts the transaction to the account, affects outstanding balance, may trigger rewards, may determine interest treatment, and later appears on a statement. Cash advances, purchases, balance transfers, fees, refunds, and reversals may have different interest, grace period, rewards, tax, and statement behaviours. If the credit platform uses multiple balance buckets, clearing must classify the transaction correctly. A cash-like MCC may be treated differently from a purchase. A promotional instalment transaction may need a separate plan. A refund may need to reverse rewards and reduce the right bucket.

For prepaid cards, posting must protect the programme ledger. Loads, unloads, purchases, ATM withdrawals, refunds, chargebacks, fees, and negative-balance recovery must reconcile to safeguarded funds where applicable. Prepaid programmes often involve third-party programme managers, processors, distributors, and sponsor banks, so the bank needs precise daily settlement and reserve controls. A small mismatch across thousands of prepaid cards can become a serious safeguarding issue.

The customer-facing balance should not be assembled independently by every channel. The mobile app, online banking, branch screen, contact centre, ATM, statement, and open-banking API should use consistent balance definitions. If one channel shows a hold as spent and another does not, customers lose trust and support calls rise. The bank should publish internal balance definitions such as current balance, available balance, pending card authorizations, posted card transactions, credit limit, available credit, statement balance, minimum payment, past due amount, and disputed amount.

A card implementation should also plan for delayed and exceptional posting. Transit systems may aggregate rides. Tipped transactions may authorize one amount and clear another. Fuel transactions may preauthorize a higher amount. Airlines and hotels may process delayed or incremental authorizations. Offline chip transactions may arrive after the customer believes the money was available. Recurring merchants may submit credentials-on-file without the customer present. The platform needs rules for these cases, and servicing teams need scripts that explain them accurately.

Consumer card journeys

Consumer card journeys are deceptively simple because customers compare them to everyday retail experiences. They expect instant issuance, easy wallet provisioning, clear spend alerts, reliable controls, fast fraud support, understandable declines, and painless replacement. The banking implementation must turn those expectations into controlled workflows.

A typical new consumer debit-card journey begins when a deposit account is opened. The product rules decide whether a card is automatically issued, offered as optional, suppressed for minors, restricted for certain risk profiles, or delayed until identity verification is complete. The card platform receives customer name, address, account link, product code, fulfilment preference, contactless eligibility, and digital-card eligibility. It creates the card record, sends embossing or digital-display data, and tracks fulfilment. If the bank offers instant digital issuance, the customer may use the card before the physical credential arrives. That creates a need for clear activation rules: digital token active now, physical card inactive until activated, ATM PIN separate, ecommerce controls defaulted according to policy.

A lost-card journey should be designed as an emergency workflow. The customer may freeze the card, report it lost, report it stolen, dispute transactions, request replacement, update delivery address, and provision the replacement token. The platform should distinguish a reversible freeze from a permanent lost/stolen block. It should identify all active tokens and credentials. It should decide whether account updater should inform merchants of a new credential. It should carry over limits and preferences when appropriate. It should retain evidence for liability handling. The customer should receive clear information about which transactions may still occur, such as offline transactions, previously authorized transactions, refunds, recurring payments, or token-based transactions depending on the action taken.

A travel journey creates a different cluster of controls. The customer may notify travel, enable international usage, raise ATM limits, rely on dynamic currency conversion choices, use contactless transit, and receive fraud alerts. The implementation should not make travel notices purely cosmetic. If travel notices influence fraud strategy, they must feed the authorization decisioning platform in time. If the bank no longer uses travel notices because behavioural models are stronger, the channel should not imply that a notice guarantees approval. Cross-border usage also requires foreign-exchange disclosure, fee posting, chargeback rights, sanctions screening, and support for merchants that clear days later in a different amount or currency.

A subscription journey is another common pain point. A consumer may store card credentials with a streaming service, telecom provider, app store, insurance company, or gym. When the card is replaced, account updater or network token lifecycle management may allow the subscription to continue. This is useful for continuity but can surprise customers who expected cancellation. The bank must explain the difference between replacing a card, blocking a merchant, revoking a token, disputing a transaction, and cancelling the underlying merchant contract. Strong servicing design gives agents the transaction history, merchant identifiers, token indicators, previous disputes, and available actions.

Youth, student, premium, secured, and credit-builder cards add product-specific detail. A youth debit card may need guardian controls, low limits, blocked categories, age transition, and educational messaging. A student card may have thin-file credit risk and simple rewards. A premium credit card may include travel benefits, lounge access, concierge services, insurance claims, annual fees, and higher fraud exposure. A secured credit card links credit line to collateral or a pledged deposit and needs clear release rules. A credit-builder card may report to bureaus, use low limits, and rely on autopay education. These are not marketing variations only; they affect data, controls, servicing, compliance, and operations.

Business and commercial card journeys

Business card journeys involve more actors and more governance than consumer journeys. The cardholder is often not the party that pays the bill. The company may own the liability, a programme administrator may manage cards, employees may use cards, managers may approve spend, finance teams may reconcile statements, and the bank may underwrite the company rather than each individual cardholder. This makes business cards powerful revenue products but also more complex to implement.

A small-business debit-card journey may start with a business checking account. The owner requests cards for employees, sets limits, restricts cash access, and chooses whether each card can spend internationally or online. The implementation must validate who has authority to request and manage employee cards. It must capture cardholder identity where required, issue credentials, link each card to the funding account, and maintain audit history for administrator actions. If an employee leaves, the company expects immediate suspension or closure without disrupting other cards or the account. If the owner changes, entitlement review becomes critical.

A commercial credit-card programme may be centrally billed, individually billed, or use a hybrid model. In a centrally billed programme, the company receives one invoice or statement and pays for many cardholders. In an individually billed programme, employees may pay and seek reimbursement, while the company may still receive data. Liability can be corporate, joint, or individual depending on market and product. These choices affect underwriting, credit limit, delinquency treatment, bureau reporting, collections, employee onboarding, statement design, and dispute authority. The platform should model liability explicitly rather than assuming all credit cards behave like consumer revolving cards.

Virtual cards are especially important for business payments. A company may generate a single-use virtual card for a supplier invoice, a travel booking, an online advertisement account, or contractor spend. Controls can include exact amount, maximum amount, currency, merchant name, MCC, validity dates, purchase order, invoice number, cost centre, and supplier ID. Virtual cards reduce supplier onboarding friction and can generate interchange revenue, but only if authorization controls and reconciliation data are strong. A virtual card that cannot match the clearing transaction back to the invoice will frustrate accounts payable teams.

Fleet, purchasing, travel, and lodge cards are specialised variants. A fleet card may restrict fuel type, odometer capture, vehicle ID, driver ID, and service categories. A purchasing card may require enhanced data and approval workflows. A travel card may integrate with travel-management companies, expense systems, and hotel or airline data. A lodge card may be held centrally by a travel desk rather than by a named traveller. These products need fields that ordinary consumer card platforms often lack. The bank should not try to force all commercial cards through a minimal consumer-card data model.

Commercial programmes also need hierarchy. A large company may have parent company, subsidiaries, regions, departments, cost centres, managers, cardholders, and cards. Limits may exist at company, unit, cardholder, and card level. Statements may be produced at multiple levels. Data files may be delivered daily to ERP or expense platforms. Disputes may be raised by cardholders but managed by programme administrators. Rewards or rebates may accrue to the company rather than the individual. The hierarchy must be part of the functional model, not a spreadsheet maintained by operations.

Tokenisation, wallets, and credential lifecycle

Modern card usage is increasingly tokenised. A customer may never type or present the physical PAN after the first wallet provisioning. A merchant may store a network token instead of a PAN. A mobile device may use a device token with dynamic cryptograms. A business platform may issue virtual cards through API. Tokenisation improves security and user experience, but it also forces the bank to model credentials more carefully.

A token is not merely a disguised card number. It has its own token requestor, domain restriction, assurance level, device or merchant relationship, lifecycle state, expiry, cryptographic profile, and event history. A wallet token on a phone is different from a card-on-file token held by a merchant. A token may be active while the physical card is not yet activated, or it may be suspended because the device is lost while the PAN remains active. The token service provider, network, wallet provider, issuer processor, and issuer host must exchange lifecycle messages accurately.

Wallet provisioning normally involves eligibility, identity and verification, token request, risk decision, terms acceptance, token activation, and card art or metadata display. The bank must decide when step-up authentication is required. A low-risk provisioning request from the customer's known mobile banking session may be approved immediately. A request from a new device, unusual location, or recently changed phone number may require one-time passcode, app authentication, contact-centre verification, or denial. Weak provisioning controls can move fraud from checkout to enrolment.

Token lifecycle events include provision, activate, suspend, resume, delete, replace, device lost, PAN reissue, expiry update, assurance update, and token requestor update. The platform should process these events idempotently. Duplicate lifecycle messages should not create duplicate tokens or inconsistent status. If a physical card is replaced, the bank must decide whether tokens continue, are replaced automatically, require customer action, or are blocked. The right answer depends on replacement reason, fraud risk, network capability, and customer expectation.

Merchant tokens and account updater create a subtle customer-experience issue. They reduce payment failure when cards expire or are replaced, which helps customers avoid service interruption and helps merchants retain revenue. But they can also cause unwanted recurring payments to continue. A functional implementation should expose merchant credential information when available, let customers manage recurring merchants where supported, and train servicing teams to explain which party can cancel the underlying service. Disputing a recurring transaction is not the same as cancelling future merchant authority.

Business virtual cards use token-like concepts even when implemented as PAN credentials. A platform may create a one-time credential with constraints and close it after use. It may generate a token for a specific supplier portal. It may pass card data through a secure API rather than display it to a human. The same principles apply: scope, lifecycle, controls, audit, reconciliation, and revocation must be explicit.

Fraud, risk, and customer protection

Card fraud controls need to balance loss prevention with payment reliability. A perfect fraud engine that declines too many legitimate transactions is not perfect. A frictionless approval engine that ignores compromise signals is not customer-friendly. Functional card design should make fraud strategy part of the operating model from the beginning.

Fraud signals can include transaction amount, merchant, MCC, country, card-present or card-not-present indicator, device, token, 3-D Secure data, previous transaction pattern, velocity, account age, customer behaviour, merchant risk, BIN attack indicators, compromised-card alerts, failed CVV attempts, declined transaction sequences, cash-out behaviour, and known fraud consortium data. The issuer may score the transaction in real time and return approve, decline, refer, step-up, or challenge outcomes depending on channel and network capability.

Consumer protection requires more than fraud scoring. Customers need alerts, simple controls, rapid lost/stolen reporting, provisional credit rules where applicable, clear liability explanations, accessible dispute workflows, and support for vulnerable customers. A fraud journey often starts with fear and confusion. The platform should let agents see transactions, authorizations, tokens, device history, recent profile changes, delivery address changes, PIN events, wallet provisioning, and previous contact. Without this context, agents ask customers to repeat information and may make poor liability decisions.

Business fraud has different patterns. Employee misuse, supplier compromise, account takeover, invoice redirection, card testing, merchant collusion, and administrator compromise can all affect commercial programmes. Controls should support segregation of duties, administrator approval, high-risk action alerts, unusual employee spend detection, virtual-card exact-match rules, and rapid suspension. A business may need investigation evidence for internal audit or insurance claims, so the bank should preserve programme-administration history and transaction data.

3-D Secure is not just a customer challenge screen. It is a risk-data and liability-shift framework. The issuer must process authentication requests, evaluate device and merchant data, decide frictionless or challenge, support exemptions where applicable, and connect authentication outcome to authorization. A successful authentication does not guarantee authorization, and an approved authorization does not mean authentication succeeded. Servicing and dispute teams must understand the distinction, especially when customers ask why a transaction passed or failed.

Fraud controls also need feedback loops. Confirmed fraud, false positives, customer disputes, chargeback outcomes, merchant compromise alerts, and operational corrections should feed model tuning and rule governance. Rule changes should be tested against historical transaction data before deployment where possible. Emergency rules may be needed during active attacks, but they should have expiry, owner, impact monitoring, and post-incident review.

Disputes, chargebacks, and adjustments

Disputes are where the card ecosystem's promise is tested. A customer who does not recognise a transaction, did not receive goods, was charged twice, cancelled a subscription, received defective merchandise, or suspects fraud expects the bank to help. The bank must translate that customer story into network reason codes, evidence requirements, time limits, provisional credit rules, accounting entries, customer communications, and final liability outcomes.

A functional dispute case should reference the customer, card, token if known, account, transaction, authorization, clearing item, merchant, amount, currency, posting date, dispute date, reason, customer statement, evidence, provisional credit decision, network filing, representment, pre-arbitration, arbitration, final decision, and adjustment entries. It should not be a free-form note with a refund button. The more structured the case, the easier it is to meet time limits, avoid duplicate credits, recover funds, and explain outcomes.

Fraud disputes and non-fraud disputes have different evidence needs. Fraud claims may require cardholder assertion, token or chip data, liability assessment, 3-D Secure data, location analysis, prior relationship with merchant, and lost/stolen timing. Non-receipt claims may require delivery evidence and merchant correspondence. Duplicate processing claims need matching transaction evidence. Cancelled recurring-payment claims need cancellation proof or merchant terms. Credit-not-processed claims need refund receipt or merchant promise. The servicing workflow should ask for the right evidence based on selected reason, not force agents to improvise.

Provisional credit must be controlled. Depending on market and product, the bank may need to provide temporary credit within defined time frames for certain consumer disputes. For business products, contractual and network rules may differ. The ledger should distinguish provisional credit from final credit. If the bank later reverses provisional credit, the customer must receive required notice. If the dispute is won, the provisional credit may become final. If the dispute is lost, the bank may debit the account again subject to rules and customer communication.

Chargeback accounting creates multiple entries. The original transaction remains part of history. The provisional credit, chargeback recovery, representment debit, final credit, write-off, fee refund, interest correction, and reward reversal may each post separately or through controlled adjustment entries. Every entry should link to the original transaction and dispute case. Finance teams need this linkage for reconciliation and loss reporting. Customers need it because statement lines can otherwise look like random debits and credits.

For business cards, dispute authority matters. A cardholder may notice the issue, but the company may own the account. A programme administrator may need visibility. A centrally billed company may want disputes reflected in invoice files and ERP data. If a virtual card was used for a supplier invoice, the dispute may involve accounts payable evidence rather than consumer-style merchant correspondence. The platform should support these business roles without exposing unnecessary personal data.

Rewards, benefits, and card economics

Cards often combine payment utility with revenue and loyalty economics. Interchange, annual fees, foreign-exchange margin, cash-advance fees, late fees, interest, merchant-funded offers, rewards liability, partner subsidies, and benefit costs all affect profitability. A functional card platform must feed accurate data to pricing, billing, rewards, finance, risk, and product management.

Rewards appear simple to customers: spend money, earn points, miles, cash back, or benefits. Implementation is more precise. The rewards engine needs eligible transaction types, merchant categories, product tier, customer status, promotion enrolment, posting date, settlement date, refund treatment, caps, accelerators, exclusions, reversals, expiry, redemption rules, and accounting treatment. A transaction may authorize today, clear tomorrow, post after currency conversion, and later be refunded. The rewards platform must know when points become pending, available, reversed, expired, or forfeited.

Benefits are also operational products. Travel insurance, purchase protection, extended warranty, lounge access, concierge support, roadside assistance, airport fast track, merchant offers, and subscription credits require eligibility data and claims processes. The bank must know whether the benefit depends on card ownership, account status, fee payment, transaction usage, ticket purchase on the card, customer residence, card tier, or network programme. Benefit disputes can become complaints when marketing promises are broader than operational rules.

Interchange and scheme fees are not usually visible to cardholders, but they shape product strategy. Debit, credit, prepaid, commercial, card-present, ecommerce, cross-border, regulated, unregulated, tokenised, and premium transactions may have different economics. A product that looks profitable on gross interchange may be unprofitable after rewards, fraud, disputes, funding cost, processing fees, charge-offs, customer-service cost, and benefit cost. Product teams need transaction-level profitability data, not only aggregate card spend.

Credit-card economics add interest and credit losses. Purchase balances, cash advances, balance transfers, instalment plans, promotional APRs, fees, payments, charge-offs, recoveries, and rewards must be allocated correctly. A customer who pays in full may be valuable through interchange and annual fee but not interest. A revolver may generate interest but also credit risk and regulatory scrutiny. A business card programme may generate interchange and foreign-exchange revenue but require credit exposure management and operational support.

The functional lesson is that cards are not a standalone payment feature. They are a revenue system with multiple ledgers and obligations. Every transaction can affect customer balance, issuer settlement, interchange income, scheme fees, rewards liability, fraud losses, dispute recoveries, tax, regulatory reporting, and product analytics.

Operational controls and servicing

Card operations should be designed around high-volume, time-sensitive exceptions. Cards create urgent customer needs: a traveller is stranded, a card is declined at a hospital, a business payroll card is blocked, a merchant charged twice, a fraudster is testing credentials, or a batch file failed before settlement. The servicing platform must give operations the right action at the right moment with strong authority controls.

Common servicing actions include activate card, resend PIN, change limits, freeze card, unfreeze card, report lost or stolen, replace card, close card, reissue due to expiry, manage token, update travel settings, enable or disable channels, refund fee, raise dispute, adjust hold, release hold, investigate decline, resend statement, update delivery address, request emergency cash, and escalate fraud. Each action should have eligibility rules, authority rules, evidence capture, customer communication, audit trail, and downstream event publication.

Agents need a consolidated card view. They should see customer identity, account status, card status, token status, recent authorizations, pending holds, posted transactions, declined attempts, controls, limits, fulfilment status, disputes, fraud alerts, profile changes, and previous contacts. They should not need to jump across seven systems during a call. Where multiple systems remain, the case-management layer should at least assemble the evidence and preserve links.

Operational queues should be measurable. Examples include failed card production, returned mail, activation failures, token provisioning declines, high-risk travel declines, unmatched clearing items, aged authorization holds, settlement breaks, dispute deadlines, chargeback representments, fraud cases, compromised-card reissue campaigns, and customer complaints. Each queue needs owner, ageing, severity, financial exposure, customer impact, and closure reason.

Maker-checker controls are important for high-risk actions. Raising a business card limit, unblocking a fraud-blocked card, refunding a large fee, reversing a posted transaction, changing a delivery address during replacement, or closing many employee cards may require approval. The platform should make approval proportionate. Too much approval slows urgent servicing; too little approval creates fraud and operational risk.

Customer communications must be event-driven. A card created, shipped, activated, declined, frozen, replaced, provisioned to wallet, charged with a fee, used internationally, disputed, or compromised may require notification. Communications should use customer preference and legal rules, but they must also be accurate. A decline alert should not say "insufficient funds" when the real reason was ecommerce disabled. A replacement notice should not promise all subscriptions will continue if the replacement reason blocks updater services.

Reconciliation, settlement, and revenue assurance

Card reconciliation is the proof that the story told to the customer matches the money moved between institutions. The bank must reconcile authorizations, clearing files, settlement files, customer postings, fees, interchange, chargebacks, scheme fees, processor invoices, suspense accounts, and general ledger entries. Weak reconciliation can hide duplicate postings, missed recoveries, settlement losses, customer harm, and income leakage.

Daily reconciliation usually starts by comparing network clearing files to issuer processor records and customer postings. Matched items confirm that the transaction moved from clearing to ledger correctly. Unmatched clearing items may indicate missing authorization, delayed presentment, duplicate file, parser issue, rejected posting, account closure, or tolerance exception. Unmatched authorizations may be expected pending holds or expired holds that should release. Settlement reconciliation then confirms that net amounts paid through settlement bank accounts match network reports and finance entries.

Interchange and scheme-fee reconciliation are revenue-assurance controls. The bank should know whether each transaction received the expected interchange or incurred the expected fee based on product, merchant, region, channel, regulated status, commercial status, token status, and network qualification. Downgrades, incorrect product setup, missing data, or merchant/acquirer classification issues can reduce revenue. For commercial cards, enhanced data may affect qualification and customer value. Revenue assurance should feed product and operations, not remain hidden in finance spreadsheets.

Chargeback reconciliation is especially important because dispute entries can span months. The bank may post provisional credit, receive chargeback settlement, receive representment, reverse provisional credit, accept loss, recover funds, or write off. Each state needs accounting and case alignment. Ageing reports should show unresolved disputes, approaching network deadlines, open financial items, and customer notices due.

Processor and vendor invoices should be reconciled to actual activity. Card production fees, personalization fees, PIN mailers, token provisioning fees, authorization processing fees, clearing fees, dispute fees, 3-D Secure fees, fraud-service fees, SMS alert fees, and statement fees can be material. A bank that never reconciles vendor charges to volumes may pay for failed events, duplicate services, or mispriced tiers.

Reconciliation design should include tolerances but avoid using tolerance as a hiding place. Small FX differences, timing differences, and rounding differences are normal. Unexplained breaks, recurring breaks, customer-impacting breaks, and breaks that cross materiality thresholds need ownership. Every break should have source, amount, currency, age, category, owner, target date, and resolution action.

Implementation data events and integration

A modern card platform should publish clear events instead of relying only on nightly files. Events let channels update customers quickly, fraud systems react, finance systems reconcile, and analytics teams understand behaviour. Batch files still matter because networks, processors, statements, and settlement often run in cycles, but event-driven design improves timeliness and explainability.

Useful card events include card requested, card approved, card created, card personalised, card shipped, card delivered, card activated, card status changed, card replaced, card closed, token provisioned, token suspended, token deleted, control changed, limit changed, authorization requested, authorization approved, authorization declined, authorization reversed, hold created, hold released, clearing received, transaction posted, transaction adjusted, dispute opened, provisional credit posted, chargeback filed, representment received, dispute closed, reward accrued, reward reversed, statement generated, payment received, delinquency status changed, and fraud case confirmed.

Event payloads should carry identifiers consistently. A transaction event should include customer ID, account ID, card ID, token ID where applicable, authorization ID, clearing ID where applicable, network reference, merchant ID, amount, currency, transaction type, channel, MCC, status, decision reason, product code, and timestamps. Sensitive data should be masked or tokenised. Downstream systems should not receive full PAN unless they are approved to handle it and genuinely need it.

Idempotency is not optional. Networks and processors can send duplicate messages. Internal services can retry. A mobile app can submit the same control change twice. If the platform cannot detect duplicates, it may create duplicate holds, duplicate disputes, duplicate replacements, or duplicate customer alerts. Each externally sourced event should have a stable idempotency key or deduplication strategy based on reference fields and timing.

Integration boundaries should be owned. The issuer processor may own authorization connectivity. The core ledger may own account postings. The card-management system may own card lifecycle. The fraud platform may own risk scoring. The token service provider may own token lifecycle messages. The rewards engine may own accrual. The dispute platform may own case workflow. The bank still owns the end-to-end customer outcome. Contracts between systems should define source of truth, latency, retries, reconciliation, fallback, and ownership of exceptions.

APIs for business cards need extra care. A company may request virtual cards through API, retrieve transaction data, update limits, or integrate with expense software. These APIs should enforce entitlement, rate limits, audit, approval rules, and data minimisation. A supplier-payment platform should not be able to create unlimited high-value cards because it knows one API credential. API actions should appear in the same audit history as user-interface actions.

Functional casebook

A strong card implementation is best tested through realistic cases that cross systems. Isolated unit tests prove calculations and validations, but card failures often happen at the boundaries between authorization, clearing, posting, token lifecycle, controls, and servicing.

Acceptance criteria for a card platform

A card platform is ready for production only when it can prove functional correctness under ordinary and stressed conditions. Approval speed matters, but correctness and recoverability matter just as much. The following acceptance areas help teams avoid shipping a platform that works only for happy-path purchases.

Card lifecycle acceptance should prove create, activate, replace, renew, suspend, resume, close, fulfilment failure, address change, PIN handling, digital issuance, and token lifecycle. Tests should include consumer cards, business employee cards, virtual cards, and products with different funding arrangements. Every status transition should have eligibility rules and audit history.

Authorization acceptance should prove supported transaction types, unsupported transaction types, domestic and international purchases, ATM cash, ecommerce, contactless, wallet, recurring payments, refunds, reversals, partial approval, stand-in, invalid cryptogram, expired card, blocked MCC, exceeded limit, insufficient funds, suspected fraud, and unavailable issuer scenarios. Tests should confirm internal decision reason, network response code, customer message, hold behaviour, and event publication.

Posting acceptance should prove authorization-to-clearing matching, clearing without authorization, expired hold, incremental authorization, tip adjustment, FX conversion, duplicate clearing, refund, reversal, chargeback, fee posting, reward accrual, statement inclusion, and GL mapping. It should also prove that customer balances are consistent across channels.

Business-card acceptance should prove programme hierarchy, administrator roles, employee onboarding and offboarding, company-level and card-level limits, central billing, virtual-card issuance, enhanced data, expense integration, and authority boundaries. A business administrator should not see or change products outside their company. A cardholder should not have administrator powers. A relationship manager should have controlled support access.

Operational acceptance should prove case creation, decline investigation, fraud case handling, dispute filing, provisional credit, replacement fulfilment, compromised-card campaign, reconciliation queues, vendor file failure, and customer communications. The bank should test not only what happens when everything works, but also what operations must do when something fails at 2 a.m. before a settlement window.

Control acceptance should include entitlement, maker-checker, segregation of duties, audit log, data masking, PCI scope, encryption, key management, retention, monitoring, alerting, and disaster recovery. A user who can view masked PAN should not automatically be able to reveal full PAN. A user who can refund a small fee should not automatically be able to reverse a large transaction. A support tool should not become a hidden payment rail.

Analytics acceptance should prove the bank can measure approvals, declines, false positives, fraud, disputes, card activation, wallet provisioning, spend, interchange, rewards cost, fee income, charge-offs, complaints, authorization latency, processing availability, settlement breaks, and revenue leakage. A product that cannot be measured cannot be managed.

Common design decisions and trade-offs

Card design involves trade-offs rather than one perfect answer. Instant digital issuance improves activation and early usage, but it increases the importance of provisioning risk controls. Strict fraud rules reduce losses, but they can embarrass customers at legitimate merchants. Rich business-card controls create value, but they require more administration and support. Account updater improves continuity, but customers may expect some replaced cards to stop recurring merchants. Stand-in processing preserves acceptance during outages, but it creates exposure.

The bank should document these decisions as product and risk choices. For example, should a frozen card block refunds? Often no, because refunds return money. Should a lost-card report block all tokens? Often yes for stolen-card risk, but maybe not for a simple damaged-card reissue. Should a business administrator be able to raise their own card limit? Usually only within policy and perhaps with approval. Should authorizations from high-risk MCCs be declined, stepped up, or allowed with monitoring? The answer depends on product, customer segment, regulation, and risk appetite.

Some decisions are market-specific. Strong customer authentication rules, debit interchange caps, credit-card disclosure requirements, chargeback timelines, credit-bureau reporting, cash-advance rules, prepaid safeguarding, and data-retention obligations differ by jurisdiction. The platform should isolate market rules so a global bank does not hard-code one country's assumptions into all programmes.

Other decisions are network-specific. Token lifecycle, dispute reason codes, account updater, interchange qualification, clearing windows, stand-in parameters, contactless limits, and data fields vary across networks and evolve over time. The bank should maintain network-rule configuration and release discipline. A card platform that requires code changes for every network bulletin will struggle operationally.

The highest-value design principle is traceability. The bank should be able to trace a transaction from customer action to authorization request, decision rules, hold, clearing item, posting, settlement, fee, reward, dispute, adjustment, statement, and GL entry. It should also be able to trace a card from application to issuance, token provisioning, status changes, replacements, controls, transactions, disputes, and closure. Traceability is what turns a card system from a collection of integrations into a controllable banking product.

The card product proposition: designing what the card is for

Before limits, chips and networks, a card is a proposition: a reason for a customer to reach for this credential instead of another. Proposition design is where card portfolios are won, and its logic is worth spelling out because every later mechanism serves it.

The debit proposition is access: the card is the account's ambassador to the world, and its design goals are ubiquity of acceptance, reliability of authorisation, and immediacy of control. Customers judge a debit card on whether it works, everywhere, every time, and on whether they can see and govern what it does, which is why real-time notifications, instant freeze, and merchant-level controls have become the debit proposition's table stakes. The credit proposition is borrowing and benefit: the card sells flexibility, rewards, protection and status in proportions that differ by segment, and its design balances the interchange and interest economics against the cost of the benefits promised, because a rewards programme is a liability that must be priced as carefully as the credit line itself.

Business card propositions answer different questions: control over employee spending, with limits by role, category and merchant; data that flows into the company's accounting without re-keying; and liability structures that allocate risk between company and cardholder as the company's governance requires. The proposition discipline across all of them is coherence: the card's features, pricing, limits, rewards and service model must tell one story to one segment, because a card that tries to be everything to everyone ends up carried by no one, and the proposition statement, this card, for this customer, because of this job it does, is the artefact every later chapter mechanism should be traceable back to.

Card issuance operations: from approval to first use

Between the decision to issue and the card's first transaction lies an operational journey with fraud, logistics and customer experience interleaved, and its design decides whether a new cardholder becomes an active one.

Production and personalisation translate the account into a credential: the card is manufactured with its chip, printed with its details, bound to the account in the card management system, and prepared for delivery, all under physical-security disciplines that treat unpersonalised stock and personalisation data as controlled assets, because a compromised production line is a compromise at the root of every card it touches. Delivery is the vulnerable middle: cards travel through postal systems to addresses of varying reliability, and the journey is designed against interception, with activation gates ensuring that a card in the wrong hands is plastic and nothing more.

Activation is the security ceremony that binds card to customer: the cardholder proves possession and identity through a channel the bank already trusts, and until that ceremony completes the card will not transact. First use completes the journey's commercial purpose: an activated card that never transacts is cost without revenue, and issuers track activation and first-use rates as core portfolio health, intervening with helpful prompts because a new cardholder who uses the card in the first weeks tends to keep using it for years. The operational measures of this journey, production quality, delivery success, activation speed, first-use conversion, are the card programme's earliest health indicators, and issuers that watch them catch proposition and logistics problems while they are still cheap.

The cardholder's year: lifecycle events on a card

A card lives a busier life than its four-year face suggests, and the lifecycle events it passes through each have designed flows behind them.

Renewal is the rhythm: approaching expiry, the replacement is produced, delivered and activated with continuity of the customer's payment relationships, and the subtlety is continuity, because an expired card breaks every subscription and stored credential the customer has, which is why automatic updating services exist and why renewal-time attrition is a measured portfolio leak. Reissue handles the disruptions: the lost, stolen, damaged or compromised card replaced under urgency, with the old credential killed instantly, fraud windows analysed, and the customer's standing arrangements protected as far as scheme services allow. PIN events, the forgotten PIN, the locked PIN, the suspicious PIN entry pattern, each carry security and service design, because the PIN is both a control and a frustration, and the journey that resets it must be easier for the customer than for the attacker.

Upgrade and downgrade move the card between products: the gold card earned, the premium fee resented, and each transition must re-map pricing, benefits, limits and insurance certificates without breaking the credential's continuity. Closure ends the relationship with its own care: final balances, residual authorisations, recurring-payment migration, and the retention decision of whether to save the relationship. Across all of these, the constant is the credential lifecycle, the state machine of the card itself, active, blocked, expired, closed, kept truthful in every system that honours or reads the card, because a card whose state disagrees between the issuer's systems is an incident waiting for a merchant.

Merchant acceptance from the issuer's seat

Issuers and acquirers sit on opposite sides of every card transaction, but the issuer that understands acceptance designs better cards, and the interface between the two sides explains much of the cardholder experience.

Authorisation quality is the first interface: the data merchants send, category codes, amounts, authentication indicators, wallet and token markers, shapes the issuer's approval decisions, and poor merchant data costs both sides, in false declines that frustrate good customers and in missed signals that let bad transactions through. Issuers therefore care, measurably, about the acceptance ecosystem's data quality, and scheme rules increasingly oblige it. Decline management is the second: every decline is a moment of customer embarrassment and merchant lost sale, and issuers manage decline rates as a portfolio metric, decomposing them into true fraud stops, insufficient funds, technical failures and false positives, because each cause has a different owner and a different fix.

The economics interface completes the picture: interchange commonly flows from the acquiring side to the issuer for ordinary purchases under applicable network arrangements; transaction types, refunds, on-us processing and other arrangements can have different economics, and local regulation may constrain the schedules, and it funds the propositions of the previous section, which is why interchange regulation reverberates through rewards programmes and card pricing years after the rule changes. Cardholders never see this machinery, but they feel its products daily, in the card that works abroad, the purchase protected when goods never arrive, and the rewards that appeared on the statement, each one a consequence of two banks and a network keeping their sides of a contract written decades ago and renegotiated continuously ever since.

Card fraud economics and the shared defence

Card fraud is an industry, and understanding its economics explains the defence's shape.

The fraudster's business model arbitrages cost against yield: stolen credentials bought in bulk are cheap and used quickly before detection; skimming and harvesting operations invest in yield per credential; social engineering invests in the highest yields of all, the customer persuaded to defeat their own protections. The defence's economics must match: prevention that raises the attacker's cost, detection that shortens the yield window, and liability allocation, through scheme rules, that concentrates the loss where the control failure occurred, which is the mechanism that keeps every party investing in its part of the wall. The result is a defence in layers, chip and token cryptography making counterfeiting expensive, authentication making usage hard, monitoring making monetisation fast to close, and customer education shrinking the social-engineering surface.

The portfolio view turns these mechanics into management: fraud losses measured in basis points of volume, attack patterns detected and countered in days, detection models retrained as the adversary adapts, and the eternal calibration between blocking fraud and approving customers, because every control strict enough to matter declines someone innocent. The honest measure of a card fraud function is not zero fraud, which exists only in portfolios with no customers, but the ratio achieved at the customer friction the proposition can bear, held steady while the adversary works full-time to break it.

Card data and analytics: the portfolio's instrument panel

A card portfolio generates some of the richest behavioural data in banking, and the analytics built on it steer proposition, risk and operations alike.

Spend analytics describe what the portfolio does: volumes by segment, category, channel, geography and time, activation and usage depth, the share of customers for whom this card is top of wallet versus drawer-bound, because primacy is the metric that predicts everything else. Risk analytics watch the other side: delinquency formation in credit portfolios, utilisation trajectories that precede distress, fraud rates by vector, and the early-warning indicators that let the issuer tighten before losses arrive. Economics analytics complete the panel: revenue per account decomposed into interchange, interest and fees, cost per account into rewards, servicing, fraud and funding, and the segment-level truth about which propositions earn their benefits and which are charity wearing a loyalty costume.

The instrument panel's value depends on timeliness and trust: portfolio indicators current enough to act on, definitions stable enough to trend, and lineage clear enough to defend when a number surprises. Card analytics at their best create a short loop between observation and action, the campaign adjusted, the limit policy tuned, the fraud rule sharpened, and portfolios with that loop compound small advantages into market position, while portfolios flying on annual reports discover their position when it is already someone else's.

Running a card portfolio: governance, vendors and change

A card programme is a permanent operation of interlocking partners, and its governance is the discipline of keeping the interlock healthy.

The vendor map is the first reality: networks, processors, personalisation bureaus, plastics suppliers, fraud platforms, rewards administrators and collections agencies each hold a piece of the customer promise, and the issuer's vendor governance, contracts with service levels, security assessments, exit plans and tested substitution, decides whether a partner's bad day becomes the issuer's bad quarter. Scheme compliance is the second: the networks' operating rules bind issuers on everything from dispute timelines to data standards, with audits and penalties attached, and the compliance calendar of mandates, each scheme's annual wave of required changes, is a permanent feature of the portfolio's change plan.

Portfolio governance ties it together: the forum that reviews proposition performance, risk posture, fraud economics, vendor health and regulatory obligations on one calendar, with the authority to act across them, because card decisions are inseparable in practice, a rewards change moves spend, which moves risk, which moves collections, and governance that sees them separately manages them badly. The final discipline is succession and resilience: the card programme must survive its own dependencies, processor outages, vendor failures, scheme incidents, with rehearsed degradation modes, because the card in the customer's wallet is a promise of availability, and promises of availability are kept by design, not by luck.

Cards and the account: how the credential and the ledger stay married

A card is not an account; it is a credential attached to one, and the marriage between credential and ledger is where many of the subtlest card defects live.

The technical reality is a chain of mappings: the card number resolves to a card record, the card record points to an account, the account holds the balance, and each link is data that must stay true through every lifecycle event. Renewal or replacement may retain or change the PAN; token references, expiry and account-updater mappings need their own lifecycle rules while the underlying account may persist. Product changes may re-point cards between accounts, and account closures must revoke applicable credentials. Reconcile each migration or mapping change so authorisation cannot use the wrong funding account or an obsolete permission.

The balance conversation between card and account runs continuously: authorisations create holds against available funds, clearing converts holds to postings, reversals release them, and each state change must agree with the ledger's view, reconciled daily in both directions. The customer-visible consequence is the available balance's honesty: what the app shows must reflect what the authorisation engine will approve, within seconds, or the customer learns to distrust both. Multi-card accounts and multi-account cards add the structural variants: supplementary cards drawing on one account with individual limits, one credential switching between accounts, business cards drawing on a company account with cardholder-level controls, each a mapping variant the systems must represent rather than approximate. The card that works is the visible tip; the mapping is the submerged machinery, and it deserves the same engineering respect as the ledger it serves.

International card usage: currency, travel and cross-border design

A card is a traveller, and its international behaviour is a designed product feature, not an emergent property.

Currency conversion is the customer's sharpest concern: when a card transacts in a foreign currency, conversion follows the applicable scheme and issuer rules, conversion date and disclosed fees; the authorisation estimate can differ from the final posted amount, and the difference between a fair, well-disclosed conversion and a murky one is a classic driver of travel-card competition. Dynamic currency conversion is the traveller's trap and the merchant's offer: the terminal proposes charging in the customer's home currency at a rate the merchant's provider sets, which must be compared with the alternative conversion and disclosed fees, and issuers educate their customers to decline it, because the choice at the terminal is a pricing decision most customers do not know they are making.

Travel functionality carries operational design: some issuers use travel notifications while others rely on fraud models that recognise the customer's devices and patterns, but the models must be fed and tuned for travel or the customer discovers their card's limits at a foreign checkout. Cross-border fraud geometry shifts abroad: different attack patterns, different merchant data quality, different dispute rules, and the fraud strategy adjusts by corridor. And the commercial card travels on business with its own needs: spend policies that differ by country, per-diem category rules, VAT-relevant data capture for expense reclaim. The card that travels well is a quiet competitive weapon, because customers remember precisely which bank's card failed them at the worst moment of a trip, and which one simply worked.

Cards in the digital-first journey: instant issuance and cardless design

The physical card is becoming one representation of a credential that increasingly lives elsewhere first, and digital-first issuance is reshaping the proposition's earliest moments.

Instant digital issuance delivers the credential to the customer's phone within minutes of approval: a token provisioned to the wallet, card details displayed securely in the app for online use, and the customer transacting before the plastic enters an envelope. The journey's design reorders the security ceremony: activation and first-use controls bind the credential to the verified app session, the physical card follows as a later representation, and fraud strategy adapts to a world where the first transaction happens nowhere near a card reader. The commercial effect is substantial: time-to-first-transaction collapses from days to minutes, activation economics transform, and the customer's first experience of the card product is the issuer's app rather than a letter, which is why digital-first issuers treat the app card-screen as the product's true front door.

Cardless design extends the direction: virtual cards generated for single merchants or single uses, spend credentials issued to employees without plastic, subscription-specific credentials that isolate recurring charges, each a credential lifecycle managed entirely in software. The disciplines of this chapter apply undiminished: the credential still maps to an account, still carries controls and statuses, still authorises, clears, reconciles and disputes, and the ledger's marriage to the credential is unchanged by the credential's form. What changes is the customer's expectation of immediacy and control, and issuers that built their credential lifecycle for software can meet it; issuers whose credential exists primarily as plastic with a postal address will spend years catching up to a design decision their competitors already made.

Final perspective

Cards succeed because they make a complex financial system feel immediate. That simplicity is earned through disciplined role definition, accurate real-time decisions, secure credentials, controlled tokenisation, reliable clearing, correct settlement, complete posting, strong reconciliation, and fair dispute handling.

A world-class card platform does not merely approve transactions quickly. It explains every outcome, protects customers and merchants, keeps balances correct, survives failures without duplicate money movement, and gives operations and finance enough evidence to prove what happened.

Standards and authoritative references

Implementations should use current official material applicable to the network, market, product, and institution, including:

• EMVCo specifications for chip, contactless, payment tokenisation, and EMV 3-D Secure.
• PCI Security Standards Council publications for PCI DSS, PIN security, point-to-point encryption, and related standards.
• Current card-network operating, processing, dispute, token, and settlement rules.
• ISO/IEC 7812 for issuer identification and PAN structure.
• ISO 8583 or the specific network message profile used by the implementation.
• Local consumer-credit, payment-services, authentication, data-protection, AML, sanctions, and safeguarding requirements.

Exact fields, fees, time limits, liability rules, interchange rates, reason codes, and processing obligations must always be confirmed against the current official source.

Retail, card, operations and business alignment

For the Malla Banking Academy Consumer & Business Banking curriculum, Cards should always be read through a retail-consumer, business-customer, card-operations and back-office lens. Retail banking means the individual customer experience: account access, card usage, payments, disputes, fees, statements, fraud protection, servicing, and clear communication. Business banking means entity authority, users, mandates, files, merchant activity, facilities, reconciliation, operational evidence, and relationship support. Card operations connects both worlds because cards touch consumer spending, business purchasing, merchant acceptance, fraud monitoring, authorization, settlement, chargebacks, accounting and servicing.

This chapter is therefore not a generic banking note. It is aligned to real retail and business banking operations: what the customer sees, what staff must control, what the core or processor records, what finance reconciles, what risk and compliance monitor, and what evidence must remain available when something goes wrong.

Follow one purchase through three different decisions

A fictional debit customer has a posted balance of 900 and no other holds. A 120 purchase authorisation reserves 120: posted balance remains 900 and available balance becomes 780. If a matching 115 presentment arrives, the posting debits the deposit liability by 115 and credits the relevant card-settlement payable; the matched 120 hold is released. Posted and available balance then both become 785. Do not subtract both the full hold and posted purchase. Partial captures, tips, offline transactions, unmatched clearing and expired holds require their own matching rules; a hold expiry does not prevent valid later clearing.

Authentication, authorisation and clearing are separate events. EMVCo's 3-D Secure overview describes consumer authentication for online card payments. A successful authentication is not a promise of available funds, final settlement or a universal liability shift. Scheme and local-law rules determine liability. PCI DSS protects payment account data; compliance validation is governed by the relevant payment brand or compliance programme, rather than a single worldwide banking statute.