🏭 Card issuing: building and running a program

Who holds what: licensed issuer, BIN sponsor, program manager, processor

An issuing program is the full set of legal, contractual, and technical arrangements through which network-branded cards are put into circulation. Four roles divide the work, and they carry different obligations and different risks. A card bears a network brand, an institution's name, and sometimes an app's name. Those three names rarely belong to the same company. How the roles are split determines who is accountable to the cardholder and who is accountable to the network.

The licensed issuer is the institution that puts cards into circulation under its own responsibility. To do so, it holds two separate authorizations that are often confused. The first comes from the regulator: a license as a credit institution, an e-money institution (EMI), or a payment institution (PI), depending on the kind of funds it will hold. The second comes from the network, which admits the institution as a member and grants it the right to put the network's brand on a payment instrument. The two authorizations cover different things, and both are required. A licensed institution that the network has not admitted cannot issue a single Visa or Mastercard card, and a network will not admit a member that lacks a license in the jurisdiction where it wants to issue.

A BIN sponsor is a licensed issuer that lends both authorizations to a third party. The third party designs and sells the product, while the sponsor remains the issuer in the eyes of both the regulator and the network. The Mastercard Rules frame this setup through the parties' status: an Affiliate is sponsored by a Principal, which answers to the network for the Affiliate's obligations. The Visa Core Rules draw the same line between a member that holds its membership directly and one sponsored by another member. The terminology differs between rulebooks, but the allocation of liability is the same. The sponsoring member is accountable to the network for the obligations of the entity it sponsors.

The program manager designs the product, acquires cardholders, runs the app, and handles customer service. It holds neither a regulatory license nor a network license, and the networks register it as a service provider to the issuer, not as an issuer. The issuer processor runs the authorization engine, maintains the card database, and connects to the network's entry point. It is registered too, in a separate category for third-party processors. The two functions are sold together or separately, and many vendors provide both. The contract should still name each one separately, because the networks register them in different categories.

• European Banking Authority register. It lists payment institutions, e-money institutions, and their agents across the European Economic Area, along with the services each one has notified.
• REGAFI, the public register of France's banking supervisor (ACPR), for institutions licensed in France and for entities operating there under the freedom to provide services.
• BaFin, whose database of supervised firms covers German institutions, and the FCA's Financial Services Register for the UK.
• Network service provider registries. Networks require their members to register the third parties acting on their behalf, and Visa publishes a directory of registered providers. A public directory does not include every registration, so asking the issuer directly remains the safest route.
• The cardholder agreement itself. It must name the institution that holds the funds, and that name takes precedence over any marketing brochure.

Getting and managing a BIN range

A BIN range is a block of card numbers reserved for one issuer. Card numbering follows an international standard, ISO/IEC 7812, whose Part 1 describes the numbering system. The number starts with an issuer identification number, the IIN, which the industry calls the BIN. The first digit of the identifier indicates the issuer's industry. The rest of the number identifies the account at the issuer, and the last digit is a check digit calculated with the Luhn algorithm (modulo 10). The standard is public. The American Bankers Association serves as its registration authority, and the networks then allocate ranges within the blocks assigned to them.

The move from six digits to eight has consequences that legacy tables handle poorly. A six-digit prefix contains 100 eight-digit ranges, which may belong to different issuers, carry different products, and fall under different interchange regimes. Visa and Mastercard set April 2022 as the date from which their eight-digit ranges became the reference. A routing table still keyed on six digits applies one set of attributes to all 100 ranges. It then misclassifies the share of traffic whose actual attributes differ from the ones it holds, and it does so silently: the symptom shows up in billing, not in authorization.

Getting a range requires network membership, or sponsorship by a member. The application to the network specifies a number to reserve and the attributes that will govern how every transaction in the range is processed. These include the issuer country, the billing currency, the product type, the funding source, and whether the cards are consumer or commercial. The network then distributes those attributes to acquirers in its BIN range files. Acquirers use them for pricing and routing.

An allocated range is not yet a live range. Activation takes three steps. The network loads the range into its routing tables, the issuer or its processor passes connection certification, and test cards run before the range opens to the public. Testing exposes gaps between the product sold and the product declared. A range may be flagged as debit while the authorization engine applies credit logic. The settlement currency chosen may also differ from the currency the issuer bills its cardholders in.

Day-to-day management then means dividing the range into sub-ranges reserved for a product, a distribution channel, or a cohort of cardholders. The network does not see this division; it knows only the declared range. The division does, however, structure the processor's card database and the authorization rules. Without documentation, the issuer can no longer tell which cards an incident affects, or what criterion separates them from the rest.

The issuer processor: authorization engine, limits, stand-in

The authorization engine is the system that approves or declines, on the issuer's behalf, every request made on one of its cards. It receives a request built by the acquirer and routed by the network, usually in a variant of ISO 8583. It has a few hundred milliseconds to respond, and its response binds the issuer. The substance of the decision is the same whatever the technology. The processor checks that the card exists and is active, authenticates the transaction, checks that the cardholder can pay, and then applies the program's risk rules.

Verifying the chip cryptogram constrains the program's entire architecture. Every chip card holds its own keys, derived from an issuer master key by diversification using the card number and its sequence number. The chip computes a cryptogram that only a module holding the master key can verify. That module sits at the processor, or at the issuer if the issuer chose to keep control of its keys. The choice is made at program launch and is very hard to reverse, since moving the keys to another module requires a new key ceremony and sometimes a reissue of the card base. Yet it is rarely on the list of points reviewed when selecting a vendor.

Engine configuration is then split across stacked layers, and confusion between them causes most production incidents. The network imposes rules that no issuer can override. The range carries the product attributes. The product profile sets default limits and blocked categories. Finally, the individual card carries the cardholder's own limits, the ones they set in the app. A rule set at the wrong level has one of two effects. Either transactions that fall outside that level bypass it, or it applies to a wider set of cards than intended.

Two EU laws shape how the authorization engine behaves: one grants an option, the other sets a limit. Delegated Regulation (EU) 2018/389 provides a transaction risk analysis exemption whose maximum amount depends on the fraud rate of the provider applying it. The exempted amount can reach €100 for a fraud rate at or below 0.13%, €250 below 0.06%, and €500 below 0.01%. Article 75 of Directive (EU) 2015/2366 governs transactions whose amount is not known in advance. The issuer may block funds only if the payer has agreed to the exact amount. It must then release the hold without undue delay once it receives the payment order.

The response code is the value that accompanies the issuer's decision and gives the reason for it. A soft decline allows the acquirer and the merchant to resubmit the transaction; a hard decline forbids them from trying again. The networks restrict repeated attempts after a hard decline and charge fees for excess requests. An issuer that returns a generic code for different situations leaves the merchant no way to recover the sale. It also drives up its own inbound call volume.

A stand-in advice is the message through which the network informs the issuer of a decision made in its name. These advices have a second effect, less visible and just as costly. Transactions approved during the outage all arrive at once when service is restored, against accounts whose available balance was calculated without them. A debit account can then go negative without any program rule having been broken. How to handle these cases is a business policy decision for the issuer, not a technical one, and it has to be made before the incident, not during it.

• Latency measured at the network's entry point, not in the processor's data center. The network applies its own maximum response time and switches to stand-in beyond it.
• A breakdown of what is billed per active card and what is billed per authorization, separating approvals, declines, reversals, and advices.
• The ability to replay a full day, because reconstructing an incident requires recovering the exact state of the counters at the moment of each decision.
• Who owns the cryptographic keys, and the key ceremony procedure, which determines whether you can switch processors without reissuing the card base.
• Contractual reversibility: the format and timeline for handing back the card database, the tokens, and the authorization history on exit.

Manufacturing, personalizing, and delivering the card

Card production runs from generating the card's data to putting the card in the cardholder's hands. It starts with a purely IT step: data preparation. From the cardholder record, the system generates the card number within the available range, the check digit, and the expiration date, and then the verification values that protect each medium. The code printed on the back, the magnetic stripe data, and the equivalent data stored on the chip each carry a different verification value. This is deliberate. It prevents anyone from building a working magnetic stripe from data read off the chip.

The application profile is the set of parameters written to the chip that governs how the card behaves at the point of payment. It is prepared in the same pass. It contains the application identifier, the cardholder verification methods, and their order of priority. It sets the thresholds above which the card requires online authorization, as well as the data the terminal must send. The profile determines how the card behaves offline, when there is no connection. A profile that is too permissive exposes the issuer to transactions it never sees. One that is too strict makes the card fail at unattended terminals and on transit, where terminals often process transactions offline.

Physical personalization then takes place at a facility whose approval depends on two sets of requirements. The PCI Security Standards Council's card production security standard sets physical and logical requirements the site must meet, from access control to the disposal of rejected cards. The networks also maintain their own lists of facilities approved to produce cards bearing their brand. A facility that is not listed cannot produce. Keys travel between the issuer and the facility under cryptographic protection, during a key ceremony involving several key custodians. The ceremony must be documented, because it will be repeated every time the vendor changes.

A virtual card is a card whose data exists without a physical medium. Preparing one follows the same steps as for a plastic card. The number is generated, the profile is built, the verification values are calculated, and the details are then delivered to the cardholder's app instead of being embossed. The gain is in lead time and unit cost, but the constraint moves elsewhere. Displaying the card number in an app creates an attack surface. Adding the card to a wallet stops being a convenience and becomes the only way to use it in a store.

Adding a card to a wallet, or provisioning, follows a different path from payment. The wallet requests a token from the network's token service provider, which queries the issuer. The issuer responds in one of three ways. It approves outright, it declines, or it requires additional cardholder verification before approving, by one-time passcode, a call to customer service, or confirmation in its own app. This third path drives the provisioning success rate, and configuring it is up to the issuer, not the wallet.

Renewals are driven by the expiration date on the card, which sets the pace for the whole program. An issuer chooses a mailing window, an overlap period during which the old and new cards coexist, and a policy for inactive cardholders. Card-on-file records at subscription merchants are updated through the networks' dedicated services: Visa Account Updater and Mastercard's Automatic Billing Updater. These services cover only the merchants that have signed up for them. At all other merchants, the recurring charge fails.

A mass reissue is the simultaneous replacement of every card in an exposed set, decided under pressure and costly either way. The networks alert the issuer when a range of card numbers has been exposed, through their compromised account programs. The issuer then has to choose between replacing the exposed cards and monitoring them. Replacing costs the plastic, the shipping, the inbound calls, and the recurring payments lost during the switchover. Monitoring costs the fraud that gets through. The decision turns on how deep the exposure goes and on the share of cardholders whose subscriptions depend on the card.

Daily settlement with the network

Settlement is the flow through which funds actually move from the issuer to the acquirer, separate from the authorization flow. An authorization places a hold at the issuer and gives the merchant a promise of payment, without moving any money. The actual movement comes later, with its own files, its own schedule, and its own identifiers. An issuer whose systems confuse the two flows can neither explain a discrepancy nor fix it. Authorization logs contain no settled amounts.

The acquirer presents transactions to the network, which clears and allocates them. The issuer then receives a clearing file listing, transaction by transaction, what it must fund. Visa runs clearing through its BASE II system and publishes settlement results in its VSS reports. Mastercard handles clearing through its Global Clearing Management System, using the IPM message format. The two systems have different names but the same structure: a detailed transaction-level feed on one side, and a net position on the other.

The net position is the balance the issuer owes the network for one clearing day. It starts with the amount of its cardholders' purchases, which the issuer must fund. The issuer then deducts the interchange earned on those same transactions, followed by refunds received and disputes won. An issuer is structurally a net debtor to the network, because interchange never covers the purchase amounts. Funds must be available every business day, before the network's cut-off time. They are held in a settlement account at a bank the network accepts.

The network protects this chain with safeguards. It assesses each member's settlement risk and can require collateral. Collateral takes the form of a cash deposit, a letter of credit, or a bank guarantee, and its amount tracks the estimated exposure. A sponsor carries this requirement for the programs it sponsors and passes it on. The program manager funds a prefunding account at the sponsor, replenished daily, and its minimum balance is as important a negotiating point as the fee.

The settlement currency is the currency in which the issuer settles its position with the network. It is declared in the range application and can later be changed only through the network. An issuer that bills cardholders in euros and settles with the network in dollars bears the difference between the network's rate and its own rate on every foreign transaction. The network performs the conversion under its own rules, and the issuer may add a markup, which it must disclose to the cardholder. The combination of the network rate and the disclosed markup directly determines the program's FX revenue line.

Daily reconciliation matches three documents: the authorization log, the clearing file, and the settlement advice. Reconciling only two leaves discrepancies that neither reveals. Authorizations that are never presented expire at the end of the network's time limit, which releases the hold on the cardholder's funds. Presentments without an authorization do happen, notably for forced-post transactions and add-ons such as tips, and they must be accepted or disputed within the deadlines set by the network rules. Amount differences between authorization and presentment are handled the same way. Monitoring focuses on the age of discrepancies rather than their number, because the network rules set fixed deadlines for accepting or disputing them.

Program economics: what comes in, what goes out

An issuing program earns revenue from four main sources, only one of which is capped by law in several markets. Interchange pays the issuer on every purchase. Network incentives reward volume and exclusivity. The FX markup earns revenue on spending abroad. Financial income comes from the funds held: interest on outstanding credit balances, or the return on balances invested by an e-money issuer.

These caps explain the geography of card programs better than tax does. In Europe, a consumer card issuer works with capped interchange revenue, which pushes programs toward commercial cards, outside the cap's scope, or toward subscription revenue. In the US, the exemption for issuers with less than $10 billion in assets has created an entire market of partner banks. Their model relies on uncapped interchange shared with the program manager. The industry's structure thus follows the scope drawn by the regulation.

Network incentives are the rebates and bonuses that Visa and Mastercard grant their members, contract by contract. They are tied to volume, brand exclusivity, or a product launch, and they often determine whether a program breaks even. Yet they are its least publicly documented line. The agreements are not public. Their aggregate weight is, since Visa reports them as a deduction from gross revenue under client incentives, and Mastercard under rebates and incentives. A business plan that books an incentive before negotiating it relies on a figure no public source confirms.

Float income is the return an issuer earns by investing the funds it holds on behalf of its cardholders. In the EU, two directives govern it. Directive 2009/110/EC prohibits an e-money institution from paying holders interest linked to how long they hold the funds, so the return stays with the issuer. In exchange, Directive (EU) 2015/2366 requires those funds to be safeguarded, either by segregating them and investing them in secure, liquid assets, or through an insurance policy or a guarantee. The available return is the yield on those assets. It moves with policy rates, and the program has no control over it.

Fraud losses are among a program's costs, and EU law puts the initial cost on the issuer. Article 73 of Directive (EU) 2015/2366 requires the payer's provider to refund an unauthorized transaction no later than the end of the business day after it is reported. Article 74 adds that the payer bears no loss if its provider did not require strong customer authentication, unless the payer acted fraudulently. The issuer therefore refunds first and seeks recovery later. Recovery targets the merchant, through the network's dispute procedures, or the provider that did not accept strong authentication. The law fixes the order: the payer is refunded before the issuer seeks any recovery.

Dormancy is the lack of use of a card that remains in the card database. It is a database problem rather than a marketing one. A card issued but never activated, a card whose holder has switched banks, a replacement card sent to an outdated address: all remain billable until they are closed. The fix is to define a dormancy criterion, measure it every month, and close the cards that meet it. Closing a card means notifying the cardholder, handling the recurring payments still tied to the card, and removing the token from any wallet where it was provisioned. That last step is most often skipped, and the token then lingers in the cardholder's wallet.

• Who the issuer is on the regulator's register, under which license category, and since when. The answer is in a public register, never in a brochure.
• Who owns the BIN range, and what happens if the partnership ends, including the notice period and what becomes of tokens already provisioned.
• Where the cryptographic keys live, and whether switching processors forces a reissue of the card base.
• Which stand-in parameters are declared to the network, who set them, and when they were last tested.
• How much prefunding is required, calculated on which weekend and public holiday scenario, and replenished through which mechanism.
• What share of the card base is active, under which definition, and what average monthly spend per active card the program achieves today.