Processor-Only Card Issuing Moves the Work, Not the Risk

Processor-only issuing sounds like a technology choice: keep your bank relationship, connect to a modern issuer processor, and retain more control.

It is actually an operating-model choice.

Stripe's current issuing documentation makes the split unusually explicit. Under its programme-management model, Stripe handles areas including bank management, compliance, KYC, AML, the ledger, and regulatory requirements. Under processor-only, most of those responsibilities move to the client. Stripe still provides network processing, card management, and authorization infrastructure, but the surrounding programme is yours to run.

That distinction matters because teams often compare the two models as “speed versus flexibility.” The harder comparison is managed dependency versus owned capability.

The Short Answer

Processor-only issuing gives a business more control over its bank relationships, licences, policies, ledger, and programme design. It also makes that business accountable for the teams, controls, evidence, and incident response behind those capabilities. The API surface may be modular; the operating responsibility is not.

If a company cannot name who owns the ledger, regulatory reporting, dispute operations, fraud policy, and sponsor-bank relationship, it is not ready for processor-only issuing.

Start With The Responsibility Transfer

The processor still connects authorization messages, manages card and token lifecycle events, applies configured controls, receives clearing records, and supports network processing.

But it cannot decide your regulatory posture or absorb every programme obligation by default. Visa's issuing-partner overview separates the BIN sponsor, issuer processor, and programme manager. The bank owns the BIN and carries network, risk, regulatory, and often settlement duties. The processor provides the issuer-side record and transaction connection. The programme manager runs the proposition across its lifecycle.

In a managed model, one provider may coordinate much of that chain. In a processor-only model, your organisation becomes the integrator of the chain.

The first deliverable should therefore be a responsibility transfer map, not a technical architecture. For every material capability, document the accountable party, execution system, approver, evidence source, service level, and emergency decision path.

The Ledger Is The First Readiness Test

Stripe's comparison assigns ledger responsibility to the client in processor-only. That single row should slow down the buying decision.

An issuing ledger must explain available balance, posted balance, holds, reversals, partial and incremental clearing, fees, refunds, chargebacks, credits, manual adjustments, and funding. It must remain consistent with processor records, sponsor-bank accounts, network settlement, and the customer-facing balance.

Hotels, fuel merchants, offline transactions, late presentments, forced posts, and expired authorizations expose the quality of the design.

Marqeta's explanation of issuer-side clearing and settlement describes the processor's role in matching clearing records to authorizations, reporting discrepancies, and supporting reconciliation. Even with good processor data, the programme still needs a defined accounting treatment and an owner for every unresolved break.

Before choosing processor-only, run a ledger proof with difficult transaction states. Reconcile authorization, clearing, settlement, and customer balance. Set ageing limits for exceptions and evidence rules for adjustments.

This is the same discipline behind three-way reconciliation: money certainty requires agreement between operational events, provider records, and cash.

Control Requires More Than Configuration

Processor APIs make controls easier to configure. They do not decide which controls are appropriate.

Someone must own KYC and AML policy, cardholder eligibility, credit or prefunding rules, MCC blocks, velocity limits, geographical controls, fraud thresholds, wallet provisioning, dispute handling, collections where relevant, and account closure. The sponsor bank and network will expect evidence that these controls operate as approved.

That creates a change-governance problem. A product manager may want to relax a merchant-category block to improve acceptance. Risk may see a new abuse pattern. The sponsor bank may require approval. Operations may need new review queues. Engineering may need to change authorization logic.

A configuration change is therefore a regulated product change. It needs policy authority, testing, monitoring, rollback, and retained evidence. Financial controls are product requirements, not back-office notes added after launch.

If you are deciding between managed and processor-only issuing, work with Rizwan to build the responsibility matrix, control catalogue, ledger proof, and launch gates before the vendor decision hardens.

Use Four Gates, Not One Business Case

The business case usually emphasizes control, partner choice, differentiation, or unit economics. Those benefits are incomplete without four readiness gates.

1. Regulatory and partner readiness

Confirm the licence or sponsor-bank model, network registrations, programme approvals, policy ownership, reporting obligations, and audit evidence. Specify the exact compliance decisions and controls the bank owns.

2. Money and data readiness

Prove the ledger, funding model, settlement accounts, reconciliation, fee treatment, reserve logic, and financial reporting across representative transaction states.

3. Operational readiness

Staff fraud, disputes, support, card lifecycle, complaints, incidents, and finance operations to the required hours and volumes. Define handoffs with the processor and bank.

4. Change and resilience readiness

Test processor outages, delayed files, wallet-provisioning failures, rule changes, funding shortfalls, and sponsor-bank interventions. Name the person who can freeze issuance, restrict spend, stop a rollout, or communicate with cardholders.

Checkout.com's card-program guidance frames its two operating scenarios similarly: use Checkout.com's issuing licence, or use your own licence with Checkout.com as processor. Its examples also show why the choice reaches beyond integration into funding, controls, localization, fraud, and reconciliation.

Measure The Programme You Chose To Own

Time to first card is a launch metric, not an operating scorecard.

Track authorization rate and latency by response code, active-card rate, token-provisioning success, fraud loss and false positives, dispute ageing, clearing-match exceptions, settlement breaks, manual adjustments, support contacts, control overrides, compliance exceptions, and contribution margin after operational cost.

Also measure multi-party recovery: time to identify the accountable party, time to decide, and time to restore a correct customer and financial state. Processor-only control has little value if every incident becomes a negotiation among the bank, processor, network, and internal teams.

Actionable Takeaway

Treat processor-only issuing as a capability acquisition.

Build the responsibility transfer map. Prove the ledger. Turn policy into executable controls. Staff the operating queues. Test incidents with the sponsor bank and processor. Only then compare commercial terms and roadmap flexibility.

Managed programmes can hide complexity behind a single interface. Processor-only programmes expose that complexity so you can control it. The exposure is useful only when your organisation can operate what it now owns.

The debate for card leaders is not whether processor-only offers more control. It does. The question is whether your team wants control of the decisions, or merely control of the API.

FAQ

What is processor-only card issuing?

Processor-only issuing means a provider supplies issuer-processing technology while the client retains its own bank relationship or licence and takes greater responsibility for compliance, KYC, AML, fraud, disputes, ledgering, and programme operations.

How is it different from managed card issuing?

In a managed model, the provider coordinates more of the bank, compliance, programme, and operational responsibilities. Processor-only gives the client more choice and control but requires more internal capability and evidence.

What should a team prove before choosing processor-only?

Prove regulatory ownership, sponsor-bank governance, ledger correctness, funding and reconciliation, operational staffing, control change management, and incident recovery across the full card lifecycle.