Card Issuing

The operating discipline behind every cardholder relationship

A customer applies for a card in a mobile app, receives an approval, adds a digital card to a wallet, and begins spending before the physical card arrives. The experience may take seconds, but the issuing institution has already performed identity checks, product eligibility, credit or funding decisions, account creation, card-range assignment, fraud controls, token provisioning, disclosures, and audit logging.

Card issuing is the discipline of creating and operating card credentials for cardholders under a network, legal, product, and risk framework. It includes product setup, customer onboarding, card and account creation, personalisation, fulfilment, activation, authorisation accountability, billing where applicable, servicing, fraud management, disputes, renewal, reissue, closure, and financial control.

The issuer does not necessarily perform every activity itself. A processor may run the card management and authorisation platforms. A programme manager may own the brand and customer experience. A personalisation bureau may manufacture cards. A token service provider may manage wallet credentials. A sponsor bank may provide network membership and regulatory sponsorship. The crucial principle is that delegated execution does not remove the licensed issuer’s accountability for the obligations assigned to it by law, network rules, and contract.

This chapter explains card issuing as a complete operating model rather than a card-production exercise.

Learning objectives

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

• Explain what card issuing includes and how it differs from acquiring and processing.
• Distinguish legal accountability, commercial ownership, customer servicing, and technical execution.
• Understand IIN or BIN sponsorship, programme structures, and PAN-range management.
• Trace the issuing lifecycle from product design to closure and record retention.
• Explain debit, credit, charge, prepaid, commercial, virtual, and tokenised issuance.
• Describe application decisioning, credit underwriting, limits, and exposure management.
• Explain physical personalisation, chip data preparation, PIN handling, and fulfilment controls.
• Describe digital issuance, wallet provisioning, token lifecycle, and account updater services.
• Understand issuer authorisation, stand-in processing, clearing, posting, billing, settlement, and reconciliation.
• Explain servicing, fraud, disputes, reissue, renewal, and portfolio migration.
• Identify architecture, operational, testing, and governance requirements for an issuer estate.

What card issuing is

Card issuing is the issuer-side lifecycle of a card product and its associated account relationship. It begins before a card exists and continues after the credential is closed.

The issuer-side operating model normally covers:

• Product and programme approval.
• Network participation and IIN or BIN arrangements.
• Customer or business onboarding.
• Eligibility and credit decisioning.
• Card account and credential creation.
• Physical or digital issuance.
• Activation and token provisioning.
• Real-time authorisation accountability.
• Clearing, posting, billing, and settlement support.
• Fraud monitoring and customer protection.
• Disputes and chargebacks.
• Card servicing and lifecycle maintenance.
• Renewal, replacement, migration, and closure.
• Finance, reconciliation, compliance, and reporting.

Issuing is not the same as card production. Production is one physical fulfilment activity. It is also not the same as processing. Processing is the execution of technical functions that may be performed by the issuer or by an outsourced service provider.

Accountability versus execution

A strong issuing model separates who is accountable from who executes each function.

The statement “the issuer owns everything” is too simple. The licensed issuer generally remains accountable for defined scheme and regulatory obligations, but commercial ownership, data processing, servicing, technology operation, and delegated decisioning may be distributed. The exact model must be documented in contracts, policies, technical designs, controls, and audit evidence.

Issuing models

Bank-owned issuing

The bank holds the network membership or sponsorship arrangement, owns the product and customer relationship, and operates most core issuing capabilities directly or through software it controls.

This model offers strong control over data, customer treatment, configuration, risk appetite, and change prioritisation. It also requires specialised skills, high availability, scheme certification, operational resilience, cryptography, fraud operations, settlement, and dispute capability.

Processor-led issuing

The issuer retains the regulated and network role while a specialist processor operates card management, authorisation, switching, clearing, or billing capabilities.

The issuer must still control product rules, risk policy, customer outcomes, access, audit, incident response, data quality, release governance, business continuity, and exit planning. Outsourcing technology is not outsourcing accountability.

Sponsor-bank and programme-manager model

A sponsor bank provides network access and regulated issuing capability to a programme operated under another brand. A programme manager or fintech may own distribution, user experience, servicing, rewards, and commercial management. A processor or Banking-as-a-Service platform may provide the technology.

The sponsor bank must understand the end-to-end programme and oversee onboarding, transaction monitoring, fraud, complaints, safeguarding or funding, product terms, marketing, data, operational resilience, and termination. A sponsor arrangement that exists only on paper is not a controlled issuing model.

Co-brand and affinity issuing

The bank issues a card with a retailer, airline, professional body, or other partner. The partner may supply branding, distribution, rewards, or customer access. The issuer usually owns credit, account administration, scheme accountability, and regulated customer obligations, subject to the exact contract and law.

Commercial and corporate issuing

Commercial programmes may issue many employee or virtual cards under a company account structure. The issuer must support programme administrators, company liability, individual liability where applicable, hierarchy, spending controls, central billing, data feeds, travel and expense integration, and enhanced reporting.

IIN or BIN sponsorship and range management

The leading PAN digits identify the issuing range. The industry still widely uses the term BIN, while current standards increasingly use IIN and eight-digit ranges.

An IIN or BIN range is allocated, sponsored, or made available under network rules. The issuer or sponsor then configures internal account ranges and product ranges within that authority. Internal PAN generation is therefore different from network allocation.

Range management includes:

• Product and geography assignment.
• Debit, credit, prepaid, commercial, or other classification.
• Processor and routing configuration.
• Network registration and reporting.
• PAN capacity forecasting.
• Token and wallet enablement.
• Fraud and performance monitoring.
• Migration and retirement planning.

Retiring a range does not always require one immediate mass reissue. Depending on network rules, programme strategy, expiry dates, processing compatibility, and contractual deadlines, migration may use phased conversion, natural expiry, targeted reissue, or a defined coexistence period. The chosen approach must prevent unroutable credentials, data conflicts, and customer disruption.

Product design before issuance

A card cannot be issued correctly until the product is configured consistently across all relevant systems.

A common failure is to configure the product in the card management system but not align the authorisation host, processor, fraud engine, billing platform, mobile app, core ledger, network tables, and general ledger. The card may be created successfully while transactions, pricing, or statements behave incorrectly.

Customer onboarding and eligibility

Card onboarding depends on the product.

For a debit card, the customer may already hold a deposit account. The issuer still needs to confirm identity, account status, product eligibility, consent, delivery details, and risk controls.

For a credit card, the issuer must normally perform affordability or creditworthiness assessment under applicable law and policy. This may involve income, employment, existing obligations, bureau data, internal behaviour, fraud checks, and identity verification.

For a prepaid product, the required onboarding depends on the programme, loading limits, redemption rights, geography, distribution method, and regulatory classification.

For a commercial card, onboarding may include the business entity, beneficial owners, authorised signatories, programme administrators, employee users, company liability, and corporate credit assessment.

Credit decisioning

Credit-card issuing requires both an initial decision and ongoing exposure management.

Application decisioning

The issuer may evaluate:

• Identity and fraud risk.
• Income and affordability.
• Credit bureau history.
• Existing exposure.
• Internal account behaviour.
• Employment or business stability.
• Requested product and limit.
• Regulatory eligibility.
• Policy exceptions and overrides.

The outcome may be approve, decline, refer, request additional information, or approve with a different product or limit.

Initial limit setting

The initial limit should reflect creditworthiness, affordability, expected usage, product strategy, and loss appetite. It should not be selected only to maximise activation or spend.

Behavioural management

After issuance, the issuer may review payment history, utilisation, spend pattern, delinquency, income changes, bureau updates, and customer requests. Limit increases and decreases require policy, disclosure, customer treatment, and model governance.

Available credit

Available credit is not simply credit limit minus posted balance. It may consider pending authorisations, instalment balances, cash sublimits, fees, interest, temporary adjustments, disputes, payments not yet cleared, and risk blocks.

Card-account and credential creation

Once approved, the platform creates the required records. Depending on architecture, these may include:

• Customer-to-account relationship.
• Card account or programme account.
• Credit line or funding-account link.
• Card record.
• PAN and expiry.
• Product and control profile.
• Billing relationship.
• Token eligibility.
• Rewards relationship.
• Fraud-monitoring profile.
• Fulfilment order.

The process must be idempotent. A retry after a timeout must not create two accounts, two PANs, or two physical-card orders.

Physical-card personalisation

Physical issuance normally involves secure data preparation and production.

Data preparation

The issuer or processor creates a controlled personalisation file containing the data required by the bureau. Sensitive data must be encrypted, transmitted through approved channels, reconciled, and retained only as permitted.

Chip personalisation

The chip is loaded with application data, keys or derived data, certificates, counters, risk parameters, and network-specific profiles. Exact EMV implementation depends on the card application and network specifications.

Printing and finishing

The bureau prints or engraves the name and card details, adds artwork, verifies quality, and prepares the carrier and packaging. Embossing is no longer universal; many cards are flat printed or numberless.

PIN handling

The PIN may be generated or selected under secure controls. PIN data must not be exposed in clear text. HSMs, approved PIN blocks, dual control, split knowledge, key ceremonies, and secure delivery methods protect the process.

Reconciliation

The issuer must reconcile requested, produced, rejected, destroyed, and dispatched cards. A missing production record is not merely a logistics problem; it is a potential credential-security incident.

Fulfilment and delivery

Physical cards may be delivered by standard post, tracked courier, branch collection, instant-issue device, or another controlled method.

Delivery design should consider:

• Address validation.
• Returned mail.
• Undelivered cards.
• Delivery evidence.
• Separation of card and PIN where required.
• Fraudulent address changes.
• High-risk or premium delivery.
• Card status before receipt.
• Customer notification.

A card should not become fully usable simply because the bureau marked it dispatched. Activation and channel controls must reflect the issuer’s security model.

Activation

Activation confirms that the credential reached an authorised customer or user and moves it into a usable state according to product rules.

Activation methods may include:

• Mobile or internet banking.
• Chip-and-PIN transaction.
• ATM transaction.
• Contact-centre verification.
• Branch activation.
• Automatic digital-card activation under controlled onboarding.

Activation is one security control, not proof that every future transaction is legitimate. The issuer still applies card status, authentication, limits, and fraud decisioning.

Digital-first issuance

A digital-first product creates a usable virtual credential before the physical card arrives. The customer may use it for ecommerce or provision it to a wallet.

Controls should include:

• Strong onboarding and device binding.
• Secure presentation of card details.
• Step-up authentication for sensitive actions.
• Restrictions before physical verification where required.
• Token provisioning risk checks.
• Clear linkage between virtual and physical credentials.
• Lifecycle behaviour when the physical card is replaced or activated.

Digital speed must not bypass product, credit, fraud, or regulatory controls.

Wallet provisioning and token lifecycle

Provisioning a card to a wallet creates or activates a token under the relevant token service arrangement.

The process may use:

• Cardholder authentication.
• Device and account risk signals.
• Token requestor data.
• Issuer identification and verification methods.
• Token assurance levels.
• Manual or automated step-up.

A device payment token is generally linked to a device or wallet instance and token requestor. It is not automatically merchant-specific. Merchant network tokens and gateway tokens are different token models.

Token lifecycle events include:

• Provision.
• Activate.
• Suspend.
• Resume.
• Delete.
• Replace.
• Update account reference.
• Device change.
• Card reissue.
• Account closure.

The issuer should be able to block a physical card while retaining or suspending selected tokens according to policy. Conversely, a compromised device token may need to be suspended without closing the underlying card account.

The issuer’s authorisation responsibility

The issuer is accountable for the rules and outcomes on its side, although a processor or network stand-in service may execute the decision.

An authorisation decision may consider:

• PAN or token status.
• Expiry and effective dates.
• Account status.
• Available funds or credit.
• Authorisation holds.
• Product and customer limits.
• Cash and merchant-category limits.
• Country and channel controls.
• EMV cryptogram or card security results.
• 3-D Secure authentication data.
• Token assurance and device information.
• Fraud score and behavioural signals.
• Velocity and recent declines.
• Delinquency or collections status.

The issuer role table should therefore be read as accountability for the outcome, not proof that one bank-owned system performs every calculation.

Stand-in processing

If the issuer host is unavailable or times out, a processor or network may apply stand-in rules. These rules can protect customer acceptance and service availability, but they create controlled exposure because the stand-in system may not have the latest balance, fraud case, payment, or status change.

Stand-in governance should define:

• Eligible products and transaction types.
• Amount and cumulative limits.
• Merchant-category and country restrictions.
• Lost, stolen, compromised, and closed-card data feeds.
• Offline and cash rules.
• Reconciliation and post-event review.
• Emergency rule changes.
• Maximum duration and incident escalation.

Clearing and posting

Authorisation reserves or approves exposure. Clearing presents the financial transaction. Posting records it in the relevant ledger or account system.

The issuer may receive clearing through a processor, network file, intraday feed, or continuous service. The financial posting may occur in real time, near real time, intraday cycles, or batch.

Responsibilities may sit in different systems:

The architecture must not assume that the card management system performs all of these functions.

Billing by product type

Billing applies differently across products.

Credit cards

The billing engine calculates statement balance, minimum payment, due date, interest, fees, payments, credits, instalments, past due amounts, and delinquency status.

Charge cards

The statement is generally due in full, although product-specific arrangements may exist.

Debit cards

Debit transactions are usually posted to a deposit account and shown on account statements rather than managed through a revolving card bill.

Prepaid cards

Transactions reduce the prepaid ledger balance. Statements, transaction histories, and disclosures depend on programme and regulatory requirements.

It is therefore inaccurate to describe the issuer as universally producing a credit-style bill for every card.

Interest and fee calculation

Credit-card interest requires careful treatment of:

• Purchase, cash, transfer, and promotional balances.
• Grace periods.
• Daily or periodic balance methods.
• Payments and allocation hierarchy.
• Fees and taxes.
• Instalment plans.
• Rate changes.
• Delinquency and forbearance.
• Refunds and disputes.

The billing platform must produce explainable results. Customers, operations, auditors, and regulators must be able to reconstruct how a charge was calculated.

Issuer settlement and treasury

The network or clearing arrangement calculates obligations between participants. The actual movement of funds occurs through the designated settlement arrangement.

Issuer treasury and finance must manage:

• Settlement-account funding.
• Currency positions.
• Intraday and end-of-day liquidity.
• Network fees and interchange.
• Settlement failures.
• Holidays and cut-off times.
• Prefunding where required.
• Reconciliation to clearing and general ledger.

A network does not necessarily move money directly between every issuer and acquirer account. It may calculate positions and coordinate settlement through approved banks or infrastructure.

Servicing the cardholder

Card servicing includes much more than replacing lost cards.

Common requests include:

• Activate or freeze.
• Change limits or controls.
• View or change PIN.
• Add or remove wallet tokens.
• Replace damaged card.
• Report lost, stolen, or compromised card.
• Change address or name.
• Upgrade or downgrade product.
• Request additional or employee card.
• Query a decline.
• Query a pending transaction.
• Raise a dispute.
• Close the card or account.

Every servicing action needs authentication, entitlement, audit, downstream propagation, customer notification, and clear failure handling.

Lost, stolen, compromised, expired, and dormant cards

These states require different treatment.

Modern issuer-host and processor controls are the primary mechanism for online status enforcement. Network exception files and offline controls may supplement them, but propagation and offline behaviour vary by network and acceptance environment.

Renewal and reissue

Renewal

Renewal normally creates a new card before expiry. The PAN may remain the same or change depending on product, network, processor, security, and migration strategy.

Replacement

Replacement may be required for loss, theft, compromise, damage, name change, product conversion, or technology migration.

Account updater and token continuity

Network account-updater and token services can reduce disruption to recurring payments when credentials change. They do not guarantee that every merchant receives or applies updated information. Customer communication and exception handling remain necessary.

Portfolio migration

Migration between processors, networks, products, or sponsor banks is one of the highest-risk issuing activities. It may require:

• PAN or IIN-range strategy.
• Card reissue or coexistence.
• Token migration or reprovisioning.
• Balance and transaction-history conversion.
• Open authorisation and clearing management.
• Recurring-payment continuity.
• Dispute and chargeback migration.
• Billing-cycle alignment.
• Settlement and general-ledger cutover.
• Customer communication.
• Rollback and reconciliation.

Fraud management

Issuer fraud controls span onboarding, provisioning, authorisation, servicing, and disputes.

Key fraud types include:

• Application fraud.
• Synthetic identity.
• Account takeover.
• Lost and stolen card use.
• Card-not-present fraud.
• Wallet provisioning fraud.
• Card testing.
• Social engineering.
• Cash and quasi-cash abuse.
• Friendly fraud and dispute abuse.
• Insider or service-provider misuse.

Real-time fraud decisions should combine transaction context with customer behaviour, device, token, merchant, authentication, velocity, location, and recent servicing events.

False declines matter. A control that blocks legitimate customers too frequently can damage trust, revenue, and customer safety. Risk strategy should measure both fraud prevented and good transactions rejected.

Disputes from the issuer perspective

The issuer receives the cardholder’s claim, determines the correct dispute path, provides required credits or protections under applicable law, and seeks recovery through network processes where permitted.

The issuer must distinguish:

• Fraud claim.
• Merchant dispute.
• Duplicate transaction.
• Cash withdrawal dispute.
• Refund not received.
• Recurring payment after cancellation.
• Processing error.
• Authorisation hold complaint.

The evidence and time limits vary by network and market. 3-D Secure, EMV data, token data, merchant evidence, authorisation results, and customer statements may affect liability, but none guarantees an outcome by itself.

Reconciliation and accounting

Issuer reconciliation connects:

• Card and account creation.
• Authorisation and reversal.
• Clearing and posting.
• Network settlement.
• Interchange and fees.
• Customer payments.
• Interest and billing.
• Refunds and disputes.
• Fraud losses and recoveries.
• General-ledger entries.

Important controls include duplicate detection, missing clearing, clearing without authorisation, unmatched reversals, stale holds, failed postings, late presentment, settlement breaks, unallocated payments, incorrect interest, and migration differences.

A card transaction is not complete merely because it appears on a customer screen. It must also be correctly represented in the account ledger, settlement accounts, fee records, and general ledger.

Issuer architecture

A modern issuer estate may contain:

• Customer and identity platform.
• Product and pricing service.
• Credit decision engine.
• Card management system.
• Authorisation host.
• Network switch.
• Fraud engine and case management.
• Limits and controls service.
• Token management service.
• Personalisation and fulfilment integration.
• Clearing platform.
• Posting engine.
• Credit, deposit, or prepaid ledger.
• Billing and statements.
• Payments and collections service.
• Dispute platform.
• Rewards engine.
• Notification service.
• Finance, reconciliation, and reporting platforms.

No system name should be used as a substitute for a responsibility map. Two banks may use the same packaged product but allocate posting, billing, tokens, disputes, and ledger responsibilities differently.

Event-driven issuing

An issuer may publish events such as:

• Application approved.
• Account created.
• Card created.
• Card dispatched.
• Card activated.
• Status changed.
• Token provisioned.
• Authorisation approved or declined.
• Reversal received.
• Clearing posted.
• Statement generated.
• Payment received.
• Dispute opened.
• Card renewed or closed.

Kafka or another event platform can distribute these events, but financial integrity still requires systems of record, idempotency, ordering rules, correlation identifiers, controlled replay, sensitive-data protection, and reconciliation.

Operational resilience

Issuing is customer-visible around the clock. Important operational capabilities include:

• 24x7 authorisation monitoring.
• Processor and network availability monitoring.
• Latency and timeout alerts.
• Decline-rate analysis.
• Stand-in activation and exposure monitoring.
• Personalisation and delivery tracking.
• Token-provisioning monitoring.
• Clearing-file and sequence controls.
• Settlement and liquidity monitoring.
• Billing and statement controls.
• Fraud and dispute queues.
• Customer-impact communication.
• Tested disaster recovery.

A processor outage, stale card-status feed, incorrect product table, or failed clearing batch can affect thousands of customers even when the mobile application appears healthy.

Testing an issuing platform

Testing should cover the full lifecycle.

Product and onboarding

• Correct product eligibility.
• Credit approve, decline, refer, and override.
• Duplicate application and retry.
• Correct account, card, and limit creation.
• Consumer, business, supplementary, and employee relationships.

Physical and digital issuance

• Personalisation-file creation and reconciliation.
• Production reject and controlled resubmission.
• Delivery failure and returned mail.
• Activation through each supported channel.
• Virtual card before physical card.
• Wallet provisioning, step-up, suspend, and delete.

Transactions

• Contact, contactless, ecommerce, recurring, ATM, cash, and token flows.
• Funds, credit, status, limit, fraud, expiry, and cryptogram declines.
• Timeout, late response, duplicate, and reversal.
• Stand-in and recovery.
• Clearing amount different from authorisation.
• Posting and stale-hold release.

Billing and finance

• Statement cycle and due date.
• Interest and fee calculation.
• Payment allocation.
• Refund and dispute effects.
• Delinquency and collections status.
• Settlement and general-ledger reconciliation.

Lifecycle

• Freeze and unfreeze.
• Lost, stolen, damaged, compromised, expired, and dormant states.
• Reissue, renewal, upgrade, downgrade, and closure.
• Token and recurring-payment behaviour after replacement.

Common implementation mistakes

• Treating the issuer as the technical executor of every function.
• Assuming outsourced processing transfers accountability.
• Calling every leading PAN range a six-digit BIN without supporting eight-digit IIN logic.
• Assuming range retirement always requires immediate mass reissue.
• Configuring the product in only one system.
• Creating cards without idempotency.
• Treating no preset spending limit as unlimited spending.
• Treating prepaid value as physically stored on the card.
• Assuming every card product uses credit-card billing.
• Assuming all posting and clearing are end-of-day batch.
• Assuming the CMS owns posting, ledger, billing, and statements in every architecture.
• Blocking a physical card without defining token behaviour.
• Reissuing a card without addressing recurring payments and account updater.
• Testing approval but not clearing, posting, settlement, and stale holds.
• Describing network settlement as though the network directly transfers every participant’s funds.

Practical example

A fintech launches a virtual debit card through a sponsor bank and processor.

The fintech owns the mobile experience and first-line support. The sponsor bank holds the network relationship and regulated issuing accountability. The processor runs card management and authorisation. Customer funds sit in an account structure governed by the programme and applicable regulation. A token service supports wallet provisioning.

A customer completes onboarding in the fintech app. The sponsor’s approved controls and delegated onboarding process create the customer and account relationship. The processor creates the card record and virtual credential. The customer provisions it to a wallet after device and identity checks.

When the customer pays, the processor executes the issuer authorisation rules. The sponsor bank remains accountable for the approved policy, fraud controls, customer protection, and network obligations. Clearing later arrives through the processor and is posted to the funding ledger. Settlement obligations are reconciled by the sponsor’s finance and treasury processes.

If the processor declines valid transactions because a product table is wrong, the fintech may receive the complaints, but the sponsor cannot say the issue belongs only to the processor. The operating model must connect brand support, processor incident handling, sponsor governance, customer remediation, and financial reconciliation.

This example shows why issuing quality depends on responsibility design as much as technology.

Functional issuer implementation catalogue

The following catalogue turns card issuing into buildable operating capabilities. Each item should be owned by a product, risk, operations, finance, compliance, or technology team; configured by effective date; represented in the servicing view; and covered by regression tests. The catalogue is intentionally practical. It describes what the issuer must configure, how the capability behaves at runtime, what evidence should be retained, and what can go wrong if the capability is weak.

Issuer programme record

Issuer programme record should have a named business owner, source system, effective-date model, authority rule, customer or company scope, and downstream event contract. Configuration should state which products, portfolios, BIN ranges, channels, currencies, customer types, and legal entities are in scope. Runtime behaviour should be deterministic: the same facts should produce the same decision whether the request arrives through mobile banking, branch servicing, processor file, API, network message, or operations queue. The issuer should retain request data, decision data, actor, timestamp, previous value, new value, reason code, customer communication where applicable, and reconciliation reference. Exceptions should route to an owned queue with ageing, severity, financial impact, customer impact, and closure reason. This prevents the capability from becoming a hidden manual process that only one operations team understands.

For consumer portfolios, Issuer programme record must be understandable to a front-line agent and explainable to the cardholder without exposing sensitive fraud rules or security data. For business and commercial portfolios, it must also respect company hierarchy, programme-administrator authority, central billing, employee privacy, and relationship-manager support boundaries. Finance should know whether the capability affects ledger posting, settlement, revenue, rewards, fees, losses, reserves, or vendor charges. Risk and compliance should know whether it affects credit exposure, AML monitoring, sanctions, PCI scope, complaints, outsourcing oversight, or regulatory notice. Testing should include happy path, ineligible request, duplicate request, timeout, reversal, downstream failure, audit retrieval, and reporting. A card-issuing platform is mature when these operational details are visible by design rather than rediscovered during incidents.

BIN and account range allocation

BIN and account range allocation should have a named business owner, source system, effective-date model, authority rule, customer or company scope, and downstream event contract. Configuration should state which products, portfolios, BIN ranges, channels, currencies, customer types, and legal entities are in scope. Exceptions should route to an owned queue with ageing, severity, financial impact, customer impact, and closure reason. This prevents the capability from becoming a hidden manual process that only one operations team understands.

For consumer portfolios, BIN and account range allocation must be understandable to a front-line agent and explainable to the cardholder without exposing sensitive fraud rules or security data. Finance should know whether the capability affects ledger posting, settlement, revenue, rewards, fees, losses, reserves, or vendor charges. Testing should include happy path, ineligible request, duplicate request, timeout, reversal, downstream failure, audit retrieval, and reporting. A card-issuing platform is mature when these operational details are visible by design rather than rediscovered during incidents.

Issuer acceptance casebook

Issuer operations control pack

An issuer should close every processing day with a control pack that proves the portfolio is financially and operationally under control. The pack should include card records created, cards activated, cards blocked, replacements ordered, tokens provisioned, authorizations approved, authorizations declined, stand-in decisions, clearing received, postings completed, holds expired, unmatched clearing, unmatched authorizations, disputes opened, provisional credits posted, chargebacks filed, settlement totals, suspense balances, fraud losses, fee income, interest income, rewards accrual, vendor activity, and customer-impacting incidents.

The pack should be segmented by legal entity, programme, BIN range, product, network, currency, processor, and customer segment where those dimensions matter. It should show opening breaks, new breaks, resolved breaks, aged breaks, owner, target resolution date, and financial value. A small unexplained break that repeats every day is not small; it is a control weakness. A large timing break may be acceptable if it is explained, owned, and resolved inside the settlement window. The issuer should review these packs through daily operations, weekly risk, monthly product performance, and quarterly governance forums.

Final perspective

Card issuing is the long-term operation of a trusted payment credential, not the one-time creation of plastic. The issuer must coordinate customer onboarding, account structures, credit or funding, secure personalisation, digital tokens, real-time decisions, billing, posting, settlement, fraud, disputes, servicing, and portfolio change.

A world-class issuer makes delegated responsibilities explicit, keeps customer and financial records consistent, controls every lifecycle transition, and can explain why a card was issued, why a transaction was approved or declined, how the customer balance changed, and who is accountable when something fails.

Standards and authoritative references

Implementations should use the current official sources relevant to the institution, including:

• Card-network operating, issuing, processing, settlement, token, and dispute rules.
• EMVCo specifications for chip, contactless, tokenisation, and EMV 3-D Secure.
• PCI Security Standards Council publications, including PCI DSS and PIN-security requirements.
• ISO/IEC 7812 for IIN and PAN structure.
• The exact ISO 8583 or network message profile used by the processor or network.
• Local consumer-credit, payments, authentication, data-protection, AML, sanctions, safeguarding, outsourcing, and operational-resilience requirements.
• Signed sponsor, processor, programme-manager, personalisation, settlement-bank, and service-provider agreements.

Exact fields, liability rules, fees, timelines, decision responsibilities, and processing obligations must be confirmed against the current rulebook, law, product, market, and contract.

Retail, card, operations and business alignment

For the Malla Banking Academy Consumer & Business Banking curriculum, Card Issuing 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.

Replacement is a credential migration, not a new customer balance

For a compromised business card, the issuer blocks the affected credential, assesses linked wallet tokens, and issues a replacement under the same governed card account where the product permits. The case must track the old and new card identifiers, token suspension or reprovisioning, recurring-payment updater policy, delivery and activation. Replacing plastic alone does not necessarily revoke a token, cancel a recurring mandate or resolve a dispute.

A 10,000 company line with 2,200 posted utilisation and 600 pending holds has 7,200 available under this simplified example. A 500 employee sublimit independently caps that employee's purchase; unused company credit does not override it. A repayment pending collection should not automatically restore availability before the product's funds-availability policy permits. Test a replacement while clearing for the old card arrives, a lost delivery, two retries of one fulfilment request, and a staff override without the required approval.

Use current EMVCo tokenisation and card specifications and the applicable PCI security programmes. The processor's implementation guide and scheme rules determine messages, key handling and token lifecycle; illustrative labels here are not certified message fields.