> ## 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.

# B19 Prepaid cards wallets and PPI operations

> Operate permitted prepaid stored-value programmes without treating their balance as a bank deposit or credit line.

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

## Definition and responsibility

Prepaid stored value is money loaded into an authorised programme for later use. A wallet is the balance container; a prepaid card is one credential used to access it. This module does not treat that value as a savings deposit or a credit limit.

| Attribute | Module definition |
| - | - |
| Entry condition | A prepaid customer loads funds, spends, requests redemption or changes programme status. |
| Owned records | Prepaid balance account, KYC/programme restrictions, load and redemption. |
| Functional output | A confirmed stored-value change linked to funding, safeguarding and settlement evidence. |
| Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. |
| Application entry points | Banking Operations prepaid-programme servicing and permitted Customer Web/mobile stored-value actions. 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) | B18 spends deposit-account funds; B19 spends previously loaded programme value. |
| [B20 Credit card accounts billing and servicing](/banking/modules/b20) | B19 has funded value to spend; B20 has approved borrowing capacity and repayment obligations. |

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

Planned operating duties: PPI issuer; programme operations; cardholder; reconciliation officer. 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: PPI-001 / INR 2,000.00 confirmed load.

| Stage | Example |
| - | - |
| Starting situation | An authorised fictional programme receives a permitted prefunded load. |
| Operator/customer actions | Verify customer tier/source, confirm funding, credit stored value once, then authorise and clear an INR 600.00 spend with no fees. |
| Expected normal outcome | Stored value becomes INR 1,400.00 and reconciles to the programme's safeguarding evidence. |
| Failure or alternate outcome | A duplicate load callback cannot double value; prohibited funding remains denied even when another credit product exists. |

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 PPI customer/tier to reconcile safeguarding

```mermaid theme={null}
flowchart TD
  START["B19-J1 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Approve PPI customer/tier"]
  N0 --> N1
  N1["accept permitted load"]
  N1 --> CHECK{"Issuer, PPI tier and funding permitted"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N2
  N2["confirm funds"]
  N2 --> N3
  N3["credit stored value"]
  N3 --> N4
  N4["authorise eligible spend"]
  N4 --> N5
  N5["reconcile safeguarding"]
  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: Load fails or chargeback arrives to notify and reconcile

```mermaid theme={null}
flowchart TD
  START["B19-J2 request"] --> ACCESS{"Actor, institution and offering permissions"}
  ACCESS -->|No| DENY["Deny without exposing other data"]
  ACCESS -->|Yes| N0
  N0["Load fails or chargeback arrives"]
  N0 --> CHECK{"State and approval eligibility"}
  CHECK -->|No| STOP["Stop: resolve evidence or eligibility"]
  CHECK -->|Yes| N1
  N1["match original funding"]
  N1 --> N2
  N2["investigate spend exposure"]
  N2 --> N3
  N3["apply issuer-approved correction/restriction"]
  N3 --> N4
  N4["notify and reconcile"]
  N4 --> 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 |
| - | - | - |
| B19-F1: PPI onboarding, KYC tier and programme restrictions | Apply the adopted prepaid programme/KYC-tier eligibility and permitted-use constraints. | An unsupported tier or use remains blocked. |
| B19-F2: Load/reload with verified source and settlement | Verify the funding source and confirm each permitted load once. | Stored value increases only with the adopted funding/settlement evidence. |
| B19-F3: Spend, refunds and available stored-value balance | Reserve and spend loaded value and match refunds to original transactions. | Balance and linked reversals agree with the authoritative programme book. |
| B19-F4: Upgrade, expiry, redemption and closure | Review upgrade, expiry, redemption or closure under adopted programme terms. | Final residual-value treatment and customer outcome are confirmed. |
| B19-F5: Safeguarding/escrow reconciliation and programme reporting | Compare programme liabilities with adopted safeguarding/escrow source evidence. | Unmatched funding or safeguarding positions remain owned exceptions. |

## Required configuration

Issuer authorisation; PPI category/KYC level; permitted loads/spend/transfer/cash-out; expiry; safeguarding. 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 PPI customer/tier → accept permitted load → confirm funds → credit stored value → authorise eligible spend → reconcile safeguarding.

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

Load fails or chargeback arrives → match original funding → investigate spend exposure → apply issuer-approved correction/restriction → notify and reconcile.

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

Authorised PPI issuer; load provenance; stored-value ledger; safeguarding bank; redemption/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 wallet, PPI balance or safeguarding ledger 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: Prohibited load source; tier limit crossed; refund after expiry; duplicate load webhook; escrow mismatch.

* 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.** Authorised prepaid issuer/category and permitted funding, use and redemption actions.

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.