> ## Documentation Index
> Fetch the complete documentation index at: https://banking.nextedge.consulting/llms.txt
> Use this file to discover all available pages before exploring further.

# B17 Card programmes issuance and inventory

> Manage issuer-owned debit, prepaid and credit programmes and the physical/virtual card lifecycle.

**Review draft • 14 October 2026 • New Banking project • Implementation not started.**

## Definition and responsibility

Card issuance manages the card credential and its lifecycle: programme, order, delivery, activation, block and replacement. Debit, prepaid and credit cards can share this process, while their funding and billing remain different.

| Attribute | Module definition |
| - | - |
| Entry condition | An eligible customer requests a card, reports loss or needs replacement/renewal. |
| Owned records | Card programme, tokenised card record, issuance order and inventory/delivery status. |
| Functional output | A confirmed usable, blocked or replaced card credential linked to the correct funding product. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Banking Operations card-programme/fulfilment workspace; Customer Web/mobile provide permitted own card requests and controls. Access is governed by the approved institution permission matrix. |

### How it differs from related modules

| Related module | Boundary and handoff |
| - | - |
| [B18 Debit card operations](/banking/modules/b18) | B17 issues the card; B18 connects a debit card to a deposit account and its funds. |
| [B20 Credit card accounts billing and servicing](/banking/modules/b20) | B17 handles card credentials/delivery; B20 handles a credit card’s limit, debt and bill. |

Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms.

Planned operating duties: Issuer programme manager; card operations; fulfilment partner; customer. Access to these duties requires the approved institution permission matrix. The bank or authorised regulated entity owns product policy and financial outcomes. Platform operators receive no automatic customer-data, fund-movement or issuer authority.

## Worked Indian example

Use the four stages below to distinguish the initial facts, the action to test, confirmed completion and the alternate result. This example exercises this module’s responsibility; related modules still own the handoffs listed above.

**Fictional requirements illustration, not seeded data or approved banking policy.** Reference: DEMO-DEBIT / CARD-001.

| Stage | Example |
| - | - |
| Starting situation | A verified eligible customer requests a physical debit card linked to ACC-001. |
| Operator/customer actions | Check issuer/programme authority, create one processor reference, personalise and track delivery, verify activation proof and enable approved channels. |
| Expected normal outcome | The card is usable only after confirmed activation; ordinary screens show a masked/tokenised reference. |
| Failure or alternate outcome | Lost issuance response is resolved against the original processor reference rather than allocating another card. |

No real customer, regulator approval, provider connection or bank operation is asserted. Illustrative amounts have currency INR and scale 2; actual economics/authority must be supplied by the institution.

## Module flow diagrams

Read each flow from top to bottom. Rectangles are actions or recorded outcomes; diamonds are decisions; labelled arrows show the next permitted route. The denial route stops the operation. The pending/unknown route keeps the original reference for investigation instead of claiming success. Each diagram corresponds to the numbered journey below.

Planned workflows are shown below. Execution depends on confirmed institution policy and interface contracts.

### Flow 1: Approve eligible card application to verify permitted use

```mermaid theme={null}
flowchart TD
  START["B17-J1 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Approve eligible card application"]
  N0 --> CHECK{"Issuer, programme and customer eligible"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N1
  N1["allocate card reference"]
  N1 --> N2
  N2["create processor record"]
  N2 --> N3
  N3["personalise/deliver or reveal through secure channel"]
  N3 --> N4
  N4["activate"]
  N4 --> N5
  N5["verify permitted use"]
  N5 --> RESULT
  RESULT{"Completion evidence verification"}
  RESULT -->|Yes| DONE["Record outcome, audit and return"]
  RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"]
  HOLD --> REVIEW["Authorised resolution; no blind retry"]
```

### Flow 2: Lost card to track final old-card status

```mermaid theme={null}
flowchart TD
  START["B17-J2 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Lost card"]
  N0 --> CHECK{"State and approval eligibility"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N1
  N1["prove/report"]
  N1 --> N2
  N2["block at issuer/processor"]
  N2 --> N3
  N3["replace with new credential"]
  N3 --> N4
  N4["transfer permitted relationships"]
  N4 --> N5
  N5["track final old-card status"]
  N5 --> RESULT
  RESULT{"Outcome verification"}
  RESULT -->|Yes| DONE["Record outcome, audit and return"]
  RESULT -->|Pending or unknown| HOLD["Keep original reference; reconcile status"]
  HOLD --> REVIEW["Authorised resolution; no blind retry"]
```

## Required features

Planned functionality is listed below. Implementation requires confirmed field definitions, permissions, state transitions and product economics for the selected offering.

| Feature | What the user or service does | Completion evidence |
| - | - | - |
| B17-F1: Programme/BIN range and processor assignments | Record approved issuer/network card-number range and processor responsibilities. | Each programme has an accountable contracted issuer and processing owner. |
| B17-F2: Application, approval and card-account linkage | Verify eligibility and link a card application to the correct debit/prepaid/credit product. | The card cannot be attached to a foreign or incompatible funding relationship. |
| B17-F3: Virtual issue and physical personalisation/order/inventory | Issue one virtual/physical card order through the contracted secure processing boundary. | Tokenised reference, inventory and fulfilment status are attributable without exposing raw secrets. |
| B17-F4: Delivery, activation, renewals and replacement | Track delivery and verify activation, renewal or replacement evidence. | Lost responses resolve the original order before another credential is created. |
| B17-F5: Card controls, lost/stolen handling and closure | Apply permitted use/block/closure changes and confirm them at the card authority. | A displayed block is backed by processor status and old-card dependencies remain traceable. |

## Required configuration

Issuer and sponsor; BIN/IIN/network ownership; processor; card type; form factor; eligibility; inventory; product terms. Store approved values in versioned, effective-dated product/programme policy. Capture the exact configuration version used by an instruction. Missing mandatory configuration blocks the dependent action; enabling a menu cannot grant legal authority.

## End-to-end journey 1

Approve eligible card application → allocate card reference → create processor record → personalise/deliver or reveal through secure channel → activate → verify permitted use.

The journey ends only when its authoritative result, customer/staff-visible result and related book or case history agree. A saved request, queue entry or HTTP acknowledgement is an intermediate state.

## End-to-end journey 2

Lost card → prove/report → block at issuer/processor → replace with new credential → transfer permitted relationships → track final old-card status.

Every transition needs an authorised actor, original version and recorded reason where required. Cancellation or client disconnection does not prove server rollback. Financial corrections retain their original reference and use linked reversal/adjustment entries rather than deleting history.

## Interfaces and data dependencies

Issuer/network/processor contract; tokenised card references; fulfilment; activation and final status. Agree stable institution, product, party and operation references; source version; as-of time; completeness; status/finality; retry rules and correction handling. Where no financial posting occurs, record the administrative/case outcome instead of inventing a journal.

All channel requests use server-verified identity and institution scope. Partner, branch and customer access is narrower than institution membership. Lists, details, search, exports, callbacks and files must enforce the same boundary.

## Current implementation and reuse

**New Banking project: proposed, not built.** No operational CMS or card inventory exists.

Reviewed legacy feature boundaries: No operational source module was found. Legacy feature presence is a reuse candidate, not acceptance or deployment evidence for this module.

## Acceptance criteria and exception scenarios

Explicit cases: Delivered to wrong address; duplicate issuance; processor success with lost response; replacement linkage leak.

* Allowed success: confirm saved/output values, authoritative status and the exact approved actor/channel.
* Denial: reject foreign institution, unauthorised branch/customer/programme and revoked or expired access without information leakage.
* Reliability: prove stale-version rejection and concurrency behaviour; retryable commands apply one economic effect; unknown financial outcomes are reconciled by original reference.
* Records and usability: preserve redacted audit, monetary precision and document integrity; verify keyboard/mobile, direct links, expired sessions, Back/Forward and return navigation. Internal web navigation preserves its workspace.

Apply the [scenario matrix](/banking/scenario-matrix) and the [shared journey rules](/banking/journeys). Timing, amounts and regulatory applicability are institution-owned inputs, not defaults supplied by this document.

## Required implementation inputs

**Status: Pending institution confirmation.** Accountable issuer, contracted networks/processors and permitted launch programmes.

Implementation dependencies and approvals are recorded in the [decision register](/banking/decisions).

[Module register](/banking/module-register) · [Offering compatibility](/banking/offering-matrix)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.