The Issuing Ecosystem: Turning a Balance into a Card

Part II · Extensions to the Architecture (Chapters 6–8) Builds on: Payment Systems, Chapter 5 (the four-party model), Chapter 6 (interchange flows to issuers), Chapter 7 (authorization, clearing and settlement), Chapter 8 (tokenization), Chapter 20 (BIN sponsors), Chapter 22 (why neobanks issue cards) New concepts in this chapter: issuer and BIN, card program manager, issuing processor, real-time authorization, just-in-time funding, spend management

1. The question from the previous chapter¶

StarMap has a PSP balance, but its employee needs a card to book a hotel that does not accept bank transfers.

The payout endpoint examined earlier is push-based: StarMap initiates and sends funds. A card payment is a pull initiated by the hotel. To let that pull draw on StarMap's balance, the PSP must offer a card. Issuing takes the issuer's position in the four-party model — cardholder, issuer, merchant and acquirer, linked by a card scheme — and turns a balance or credit line into a card merchants can charge.

We start with the authorization moment, separate the issuing-side roles, then examine their licensing and engineering requirements.

2. What happens on the issuing side when a card is used?¶

An employee spends €320 at a Berlin hotel. The card transaction lifecycle viewed the sequence from the merchant and acquirer side. Now watch the issuing side:

The final row supplies the economic incentive. Interchange showed an issuer receiving $1.80 from a $100 transaction, and neobank anatomy connected that revenue to card issuance. The issuing side receives interchange, so a PSP's card product can generate revenue as well as giving customers a way to spend.

This chapter covers cards backed by balances: debit, prepaid and corporate spend cards. Credit cards add underwriting, billing and collections, which are outside this course.

3. The roles: the issuer takes scheme responsibility, the program manager builds the product¶

The phrase "issuing side" hides several roles:

The relationship between issuer and program manager is central. The issuer has the scheme membership, BIN and scheme liability. The program manager has the customer-facing brand, product and relationship. They can be one company: Revolut is a principal member and issues in Europe. Or they can be separate: many US fintech cards are issued by specialist banks such as Sutton Bank, Pathward or Lead Bank, with the fintech managing the program.

When an issuer provides its BIN for another company's program, this is BIN sponsorship, introduced in the industry role map.

The structure resembles acquiring:

Schemes work through members, and membership has entry requirements. Sponsorship lets companies that cannot or do not want to obtain membership build products under a member's responsibility. It creates a corresponding intermediary role on both sides.

4. Licensing requirements: who can issue?¶

Issuing has the same two broad permission layers as acquiring: payment regulation and scheme membership.

Payment permissions: issuing payment instruments is a regulated payment service. Where prepaid or corporate cards use held customer balances, the provider also needs the relevant balance-core permissions. EU and UK EMI permissions can cover the combination.

Scheme membership: eligibility to be a principal member with an own BIN differs by market:

Where scheme eligibility is tied to bank status, nonbanks need a sponsor. Where a payment licence is accepted, nonbanks can obtain their own membership. This resembles direct clearing access in pay-in endpoints: the rule setter's treatment of nonbanks determines the available route.

Sponsorship brings dependency. Since the issuer answers to the scheme, it reviews the program manager's customers and risk controls, requires security deposits and can terminate the relationship. Regulatory action involving US sponsor banks around 2024 led some to tighten partnerships, forcing fintech programs to pause or migrate. That is a practical consequence of the dependency.

5. Engineering requirements: the authorization deadline and subsequent reconciliation¶

At authorization

The issuing side has only seconds to answer. In the timeout behavior assumed here, an unanswered request is declined. Four checks must run automatically:

There are two ways to supply the spendable balance:

The second is just-in-time funding, or JIT funding, standardized as a product by providers such as Marqeta. It connects the card directly to the balance core: each approved authorization creates a reservation on the core ledger. The core must now serve as a continuously available authorization system as well as a reconciled record of funds.

After authorization

Authorization creates a reservation. Three more processes follow:

• Different clearing and authorization amounts. The hotel authorizes €320 but clears €335. A US fuel station may authorize $1 before clearing the actual purchase. An authorization that never clears must expire and release its reservation. Each case needs explicit ledger handling.
• Reconciliation. Daily scheme files must agree with authorization records, cardholder deductions and debits from the scheme settlement account. This adds another record source compared with a basic pay-in.
• Chargebacks. If the cardholder denies a purchase, the issuer raises the dispute against the acquiring side. This is where the chargeback seen from the acquirer's perspective begins.

Tokenization

When an employee adds the card to Apple Pay, the issuing side integrates with scheme token services and verifies the cardholder during provisioning. Subsequent transactions carry a token rather than the underlying card number. Card-not-present payments explains the mechanism; the issuer must incorporate it into authorization.

6. How issuing becomes spend management¶

Once a program manager controls the authorization rules, it can do more than supply an employee card:

• Issue a virtual card per supplier, with a set amount and expiry, then close it after use.
• Enforce merchant-category, per-payment, daily and monthly limits.
• Prompt employees for receipts after each authorization and match them to accounting categories.
• Separate travel, software and advertising cards, blocking overspending before it happens.

This is spend management. Providers such as Ramp and Brex in the US, and Airwallex, Payhawk, Pleo and Spendesk in European markets, combine the issuing roles with rules and accounting integrations.

The business model differs across the US and Europe for the same reason discussed in neobank anatomy: interchange economics.

Similar technology can support different pricing because the revenue available from card spending differs.

7. Put issuing back into the model¶

In the PSP model, issuing is a payout endpoint connected to the balance core, with real-time authorization. The merchant initiates a pull; the core reserves and later deducts funds. In the earlier payout endpoint, the customer initiates a push. Their funding arrangements also differ: local push payouts use domestic pools, while issuing funds scheme settlement accounts for scheme clearing and settlement.

Adding acquiring, local methods and issuing to the PSP model gives this capability map:

The map lists capabilities that change responsibilities within the architecture. Other PSP products fall into three groups: software such as billing, tax, fraud tools and identity checks; financial products needing additional permissions or a bank partner, such as yield, merchant financing, credit cards and FX forwards; and platforms supplying the core and endpoints to other companies. The first two are outside this course. The third is the supplier form described in the end-to-end walkthrough.

8. The questions this raises¶

Every row above uses fiat money and bank or card-scheme rails, with their operating hours and settlement cycles. In our next scenario, StarMap wants to pay a Philippine developer on Friday night but its existing route cannot deliver until Monday.

The chapter on what stablecoins are explains that transfers on one shared ledger can clear and settle together, around the clock. Where would stablecoins fit in this capability map? The next chapter answers that question.

9. Self-check questions¶

1. A US fintech's name appears on a corporate card, while a bank's name appears in small print on the back. Which is the issuer, which is the program manager, and who might process the card? Why can regulatory action against the bank affect the fintech's cards?
2. StarMap's PSP chooses JIT funding over preloading. What must its core do, and what happens during a ten-minute maintenance outage?
3. Using the interchange explanation shared with neobank anatomy, explain the contrasting pricing models of Ramp and Payhawk.

10. Answers¶

Try answering before reading on.

1. The bank is the issuer, holding the BIN and scheme membership. The fintech is the program manager, responsible for the product, customers and controls. A processor such as Marqeta or Galileo may connect them to the network; the card branding does not identify it. If the bank tightens programs or stops supporting them, the fintech loses the issuing foundation it relies on. Moving to another issuer may require new card numbers.

2. The core must answer within hundreds of milliseconds at all times, reserve funds for authorizations, convert reservations to deductions at clearing and release expired authorizations. Under the timeout policy assumed here, a ten-minute outage causes requests during that interval to time out and decline, wherever employees are spending. Preloading avoids dependency on the program manager's core for that real-time check, at the cost of prefunding and another reconciliation relationship.

3. US corporate-card interchange often exceeds 2%, creating a revenue pool from spending that can support free products or cashback. The program manager receives an agreed share of that issuing-side revenue. European corporate-card rates, although outside consumer caps, are generally lower, making subscription revenue more important in the comparison. Similar technical products face different pricing economics.

Previous: Chapter 7 · Local Payment Methods: Why Integrate a Hundred Ways to Pay? Next: Chapter 9 · Stablecoins: Customer Balances, On-Chain Endpoints or a Treasury Bridge?