A detailed view of the issuer, the card network, and the proof layer.
Veritas Card Issuer describes how a bank could issue virtual or physical cards backed by its own account and ledger controls, while using ICP to make each card identity and selected lifecycle or reserve commitments verifiable. The card still pays through ordinary card acceptance and scheme routing; blockchain is an evidence layer alongside that service, not the service that authorizes a purchase.
A card-issuing capability is the issuer-side service that creates and manages card products and their lifecycle: application, issuance, activation, controls, authorization, holds, capture, replacement, freeze, expiry and cancellation.
Veritas Card Issuer adds a proposed ICP Card Identity for each card, linked to one customer or treasury Wallet Canister. It does not make a card itself a cryptocurrency or turn the blockchain into the issuer processor.
It is for customers and corporate treasuries that want familiar card-network acceptance with stronger evidence about who issued a card, which lifecycle state it is in, what policy version governs it, and which collateral/reserve records support the programme.
Those proofs can help authorized parties verify that a record has not changed since commitment. They do not replace legal issuer accountability, custody verification, scheme contracts, reconciliation or audit controls.
At a high level: verify the customer; establish a Wallet Canister; check eligible funding and collateral; create a unique card identity; securely provision a payment credential through an issuer processor; then answer payment requests from Veritas systems.
At purchase, the merchant/acquirer sends an authorization through its card scheme to Veritas. Veritas validates the request, checks card status, policy and available ledger funds, places a hold on approval and sends approve/decline back over the network. Clearing arrives later; a valid capture posts to the ledger. ICP proof work runs separately and asynchronously.
ICP can hold a unique Card Identity plus carefully minimized references or cryptographic commitments for lifecycle state, control version and reserve evidence. A later verifier can check a proof against the committed digest.
Follow the stages from customer admission to verifiable evidence. Every row states the owner, action and control boundary. Card-network authorization and the ledger are the financial hot path; ICP sits beside it as a non-blocking proof path.
This is the live decision loop in the proposed model. The scheme carries the request and response, Veritas applies issuer rules and records a hold if approved. Authorization is not final settlement, and ICP is not called on this hot path.
Clearing is the later transaction record submitted by the merchant side; settlement is the movement of funds between participants under their agreements. Veritas reconciles those scheme records and settlement statements against its own append-only ledger, preserving linked corrections and investigation evidence.
outline-level planning text — simulated demo content, to be replaced by the programme's real materials
A stage-by-stage view of the issuer, the card network and the proof layer, with each stage's owner and control boundary stated.
Reviewers who need the whole issuer flow — admission, identity, authorization, clearing, reconciliation and proof.
No Visa/Mastercard affiliation, issuer licence, processor contract, certification, reserve backing or measured latency is claimed.
Programme materials that would define scope, controls and steps:
outline-level engineering text — planned work is labelled, never claimed as shipped
Ten stages, each with an owner, action and control boundary, from customer admission to anchored proof.
The scheme carries request and response; clearing arrives later and a valid capture posts once.
Issuer ledger, scheme clearing file and settlement statement compared; corrections are linked entries, never deletions.