> ## 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. # B20 Credit card accounts billing and servicing > Manage revolving credit from underwriting to statements, repayment, collections and closure. **Review draft • 14 October 2026 • New Banking project • Implementation not started.** ## Definition and responsibility A credit-card account records revolving borrowing: sanctioned capacity, used exposure, billed dues, payments and overdue status. Issuing a plastic/virtual card is separate from creating or servicing this credit relationship. | Attribute | Module definition | | - | - | | Entry condition | An accepted credit-card application is approved/activated with a sanctioned credit limit, a spend clears, a bill is due or payment arrives. | | Owned records | Revolving credit account, limit, receivable, statement and allocation. | | Functional output | Current exposure, available credit and customer dues linked to accepted terms and postings. | | Configuration | See **Required configuration** below. Parameters require institution-approved values and effective versions. | | Application entry points | Banking Operations credit-card servicing and permitted Customer Web/mobile statements, repayments and controls. Access is governed by the approved institution permission matrix. | ### How it differs from related modules | Related module | Boundary and handoff | | - | - | | [B14 Loan servicing and repayment](/banking/modules/b14) | B14 services scheduled loan contracts; B20 services revolving card bills and available credit. | | [B21 Card authorisation clearing and settlement](/banking/modules/b21) | B21 confirms card message/clearing facts; B20 turns those facts into credit exposure and billing. | Read the [module comparison map](/banking/module-boundaries) for the whole platform and the [glossary](/banking/glossary) for shared terms. Planned operating duties: Cardholder; credit-card operations; risk; billing; collections. 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: CC-001 / INR 50,000.00 example sanctioned limit. | Stage | Example | | - | - | | Starting situation | A credit card makes an illustrative INR 3,000.00 purchase, with no other holds or fees. | | Operator/customer actions | Reserve and clear the purchase, generate the adopted statement, receive repayment and apply its approved allocation. | | Expected normal outcome | After matching purchase, available credit is INR 47,000.00; a confirmed full INR 3,000.00 repayment restores INR 50,000.00 in this simplified example. | | Failure or alternate outcome | A minimum/partial payment does not mean paid in full. Interest, grace and minimum-due rules must come from accepted product terms. | 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 credit to reconcile ```mermaid theme={null} flowchart TD START["B20-J1 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Approve credit"] N0 --> CHECK{"Credit sanction, consent and limit valid"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["accept terms"] N1 --> N2 N2["issue/activate"] N2 --> N3 N3["authorise/clear spend"] N3 --> N4 N4["generate statement"] N4 --> N5 N5["receive/allocate repayment"] N5 --> N6 N6["update available credit"] N6 --> N7 N7["reconcile"] N7 --> 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: Customer pays partially or misses due to retain correction history ```mermaid theme={null} flowchart TD START["B20-J2 request"] --> ACCESS{"Actor, institution and offering permissions"} ACCESS -->|No| DENY["Deny without exposing other data"] ACCESS -->|Yes| N0 N0["Customer pays partially or misses due"] N0 --> CHECK{"State and approval eligibility"} CHECK -->|No| STOP["Stop: resolve evidence or eligibility"] CHECK -->|Yes| N1 N1["apply approved economics"] N1 --> N2 N2["age dues"] N2 --> N3 N3["notify/collect"] N3 --> N4 N4["resolve hardship/dispute"] N4 --> N5 N5["retain correction history"] 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 | | - | - | - | | B20-F1: Application, underwriting, sanction and consent | Link verified application/underwriting and accepted credit-card terms. | An active account has accountable sanction and consent evidence. | | B20-F2: Account/primary/add-on limits and exposure | Track primary/add-on use within the adopted account and card-level limits. | Aggregate exposure cannot exceed independently checked current authority. | | B20-F3: Statement generation, due dates and receivables | Generate statements and due components from confirmed receivables and billing policy. | Statement total, due date and source entries reconcile. | | B20-F4: Repayment allocation, interest/charges and instalments | Allocate verified repayments and apply approved interest/charge/instalment calculations. | The exact policy version and resulting debt/availability are traceable. | | B20-F5: Limit changes, delinquency, disputes and closure | Review limit changes, overdue cases, disputes and closure dependencies. | Closure or correction is confirmed without dropping outstanding receivables or history. | ## Required configuration Credit/cash limits; statement cycle; due date; interest/grace; fees; minimum due; allocation; instalments; closure. 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 credit → accept terms → issue/activate → authorise/clear spend → generate statement → receive/allocate repayment → update available credit → reconcile. 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 Customer pays partially or misses due → apply approved economics → age dues → notify/collect → resolve hardship/dispute → retain correction history. 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 eligibility; credit policy; exact billing/interest; repayment; bureau; clearing/settlement. 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 credit-card account engine, billing or repayment allocation 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: Full versus minimum payment; refund across cycle; cash advance; add-on combined limit; unbilled closure. * 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.** Credit-card variants, billing/interest rules, repayment allocation and limit-change authority. 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.