Delegated card
A payment credential used by one party and paid for by another, where each of them is verified by a licensed institution in their own jurisdiction. This page proposes a name and a definition for an arrangement that exists in fragments and does not yet have one.
Status. This is a draft, not a standard. The term is descriptive and unowned: anyone may use, adapt or reject it. It describes an arrangement, not a product. DELFINA is one implementation, and there may be others.
This page is openly licensed: you may republish it, adapt it or fork it. Corrections and disagreements are welcome at hello@delegated.finance.
What a delegated card is
A delegated card is a payment credential where:
- spending on the credential is funded by a sponsor, a person or an organisation, through a single verified funding source;Funding timing is now neutral. v0.1 required the sponsor to be “charged at authorisation”. Real-time and prefunded designs are described as configurations in the next part.
- the credential is issued in the recipient’s own name and used by them; the recipient owns no balance on it and takes on no debt for it;Added that the credential is in the recipient’s own name. Ownership is now stated about the recipient only, since it depends on the legal arrangement on the sponsor’s side.
- the sponsor keeps authority over the credential after issuance: limits, permitted merchant categories, suspension and revocation;
- and the sponsor and the recipient are verified by different licensed institutions, each under the rules of its own jurisdiction.
The first three conditions describe a supplementary card. The fourth is what makes it something else.
v0.1 had a fifth condition: “and neither institution’s licence alone authorises the issuance.” That test now sits below as one implementation’s target configuration, so that the open category does not reproduce one engine’s eligibility test.The fifth condition was moved out of the definition, as recommended in review.
- Funding timing
- Real time: funding is requested from the sponsor’s source as each purchase is authorised, without a prefunded balance owned by the recipient. Charge or hold timing and settlement arrangements depend on the licensed partners. Prefunded: the sponsor holds a balance with a licensed provider, and purchases draw on it. Blanja and Amanah are being designed for real time.
- Where the card is issued
- By an institution in the recipient’s jurisdiction, as issuer of record under its own licence, or by an institution in the sponsor’s jurisdiction. DELFINA’s first proposed corridor uses issuance in the recipient’s jurisdiction.
- DELFINA’s target case
- Arrangements where neither institution’s verification scope alone covers what issuance requires, and the two together do. This was condition five in v0.1.
Where it sits against existing categories
Most card types differ on whose money it is. The closest comparison is with the supplementary or authorised-user card, which answers that the same way: someone else’s money, someone else’s rules. A delegated card is a supplementary card freed from the single-jurisdiction constraint.
Swipe sideways to compare all five →
| Credit card | Debit card | Prepaid card | Supplementary / authorised user | Delegated card | |
|---|---|---|---|---|---|
| Whose money | The issuer’s credit, repaid by the holder | The holder’s deposit | A stored balance the issuer owes | The primary account holder’s | The sponsor’s, by real-time charge or a sponsor-level balance |
| Who is liable | Typically the holder, to the issuer | The holder, within their balance and terms | The issuer owes the stored value; programme terms allocate losses | Typically the primary account holder | Typically the sponsor, under its agreement with its institution; the recipient’s position depends on programme terms |
| Where spending is paid from | Repayment by the holder | The holder, or anyone paying into the account | Depends on the programme; often the holder or others | Repayment by the primary | Only the sponsor’s verified funding source; no cash-out |
| Who sets the rules | The issuer sets the limit | The balance and the issuer’s limits | The programme | The primary sets sub-limits where the issuer offers them | The sponsor, within the issuer’s own controls: categories, ceilings, suspension, expiry |
| Who verified the holder | The issuer | The issuer | The programme or issuer, to a level set by the programme’s risk tier | The same issuer, under its own framework, where it verifies the user at all | A licensed institution in the holder’s own jurisdiction |
| Across borders | The issuer onboards the holder under its own framework | Same | Same | The user is generally onboarded under the issuer’s own framework, so it can only add people it is able to verify itself | Two institutions in different jurisdictions, each acting under its own licence; neither extends into the other’s |
Four of six rows broadly match the supplementary card. The last two are where they diverge.
Properties, and what they might meanRetitled from “Consequences”. Each property is now separated from its possible regulatory consequence, which has to be confirmed per jurisdiction.
Naming a category changes nothing on its own. What matters is that the arrangement differs, so existing rules may land in different places. The left column describes the arrangement. The right column describes what that might mean, which has to be confirmed jurisdiction by jurisdiction.
None of this is an exemption. The rules apply as written; they may land differently because the arrangement is different. A category name describes the arrangement. It does not establish a regulatory treatment.
What drops out, stays and moves, by configurationSplit into real-time and prefunded variants. In v0.1 the balance disappeared everywhere; a prefunded design keeps one on the sponsor’s side.
If the recipient holds no balance, much of the machinery for stored-value cards has nothing to attach to on the recipient’s side. Some complexity relocates instead of disappearing, and where it goes depends on the funding configuration.
| Real-time funding | Prefunded | |
|---|---|---|
| Recipient’s ledger | None. An authorisation record of spending, not custody. | None for the recipient. A sponsor-level balance ledger instead. |
| Paying for spending | No recipient-side funding network. One call to the sponsor’s verified source per purchase. | The sponsor pays into its balance through its own provider. No recipient-side funding network. |
| Safeguarding | Nothing is held for the recipient. | The sponsor balance may need safeguarding, depending on the jurisdiction. |
| Dormancy and closure | Revocation, not wind-down. Nothing residual. | The unused sponsor balance has to be returned or reallocated. |
| Where it gets harder | Funding sits inside the authorisation path, with a hard response deadline. If the funding source is unreachable, the purchase declines. The issuer is exposed between authorisation and settlement. | Less latency risk at the till, but balance management, reconciliation and return obligations come back. |
Unchanged in both
- Full customer due diligence on the recipient by the local licensed institution. This is the check the arrangement rests on.
- Sanctions and watchlist screening on both parties, ongoing.
- Authorisation and spending controls, with the same mechanics as any controlled card.
- Settlement with the card network, and the issuer’s scheme obligations.
- Statements and an audit trail, arguably heavier, since two parties need visibility instead of one.
What is not settled
These are unresolved. Where a product built on this arrangement has chosen an answer, it is shown as proposed, for comment. Proposed answers are product decisions, not settled practice.Proposed answers added from product decisions made since v0.1. Questions 09 and 10 are new.
- 01
Where does a refund land when there is no balance?
A merchant refund arrives at the card. With stored value it credits the balance; here there is none. Holding it as a credit against the card reintroduces stored value. Refusing refunds is unacceptable to merchants and consumer-protection regimes.
Proposed, for real-time designsCredit the refund back to the sponsor’s funding source and show it in the shared record. Whether every processor offers that reverse path is still open. - 02
Who funds an offline or stand-in approval?
Some transactions are approved without reaching the issuer at all: contactless below a floor limit, transit, and network stand-in when the issuer is unreachable. No funding call is made, the transaction still settles, and the sponsor’s controls were never consulted. This remains the sharpest edge in the model.
- 03
How do incremental and pre-authorisation holds behave?
Hotels, fuel pumps and car hire place an estimated hold and adjust later. A hold against a just-in-time funding source is not obviously the same as a hold against a balance, and a later adjustment may meet controls that have since changed.
- 04
Who holds the dispute right?
Scheme chargeback rules assume the cardholder and the payer are the same person. Here the recipient made the purchase and the sponsor’s funds were charged.
ProposedDisputes are raised through the issuing institution, as the card’s issuer of record, and both parties see the status in the shared record. Whose consent is needed to raise or withdraw one is still open. - 05
What protections attach to the recipient?
The recipient spends under rules set by someone else, on a credential that can be suspended without their agreement.
ProposedThe recipient sees every rule before the card is issued and is shown every change. Notice before revocation, and a route to challenge a refusal, are still open. - 06
Is merchant-level restriction enough?
Category controls act on the merchant, not the item. A card can be stopped at a liquor store but not from buying a bottle in a supermarket. A spending record shows the shop and its category; it does not prove what was bought, or that a purchase was needed. Whether that is adequate for purpose-bound programmes is open.
- 07
What should the card face show?
Networks require product-type identification. There is a tension between transparency at the point of sale and marking the holder as a dependant in front of a cashier.
ProposedThe card carries the recipient’s own name. Whether it should also carry a product designation is still open. - 08
What happens on the sponsor’s death, insolvency or withdrawal?
The recipient’s spending depends on an account they do not control. There is no established practice for notice, wind-down or transition.
- 09 · new
Who sees attempts that the rules decline?
A declined attempt can be useful to an auditor and intrusive within a family.
ProposedFor a family arrangement, declined attempts are not shown to the sponsor. For a funded programme, they appear in the programme record for staff and auditors. The recipient is told when a purchase is declined. Whether a separate private attempt history is available remains a product-design question. - 10 · new
Can the recipient be a minor?
A parent abroad may want to support a child at home directly.
ProposedA supervised card in the minor’s own name, where the issuing institution offers cards for minors. Eligibility, consent and age rules follow that institution’s own framework.
On the term itself
“Delegated card” is proposed as a description, not a brand. It is unowned. Categories in payments have usually been named descriptively and by adopters rather than by a single company: “credit card” first appeared in a nineteenth-century novel, and “debit card” has no clear coiner. If the term is useful, it will be used; if a better one exists, it should replace this one.
What is being proposed here is the definition, not the word.
Corrections welcome
This is v0.2. It will still be wrong in places. The most useful reply names a specific row in the table, or a specific open question, and says what is missing or mistaken. Practitioners at issuers, processors, licensed institutions and programme teams are the intended readers.
You don’t need permission to take this further. If an institution, network or working group develops a definition that supersedes this one, this page will point to it instead of competing with it. The aim is a shared definition, not this particular document.
Write to hello@delegated.finance.
Licence and citation. © 2026 Carlo Alejano. This page is published under a Creative Commons Attribution 4.0 International licence (CC BY 4.0). You may copy, adapt and republish it, in whole or in part, including commercially, provided you credit the source. Earlier versions remain available under the licence they were published with.
Scope. This licence covers the text of this page. It does not license any patent, trade mark or software. DELFINA’s reconciliation architecture is the subject of a separate patent application, filed in Singapore and pending.
Cite as: Delegated card — a working definition, v0.2, delegated.finance/delegated-card. Cite v0.1 as delegated.finance/delegated-card-v01.
Changelog
- v0.2 · 6 October 2026. Funding timing made neutral, with real-time and prefunded configurations. The card is now stated to be in the recipient’s own name. The “neither licence alone” test moved out of the definition into DELFINA’s target configuration. Comparison table qualified as typical arrangements. “Consequences” reframed as properties and possible consequences, to be confirmed per jurisdiction. Implementation section split by configuration. Proposed answers added to questions 01, 04, 05 and 07; questions 09 and 10 added. Contact changed to hello@delegated.finance.
- v0.1 · 3 September 2026. Initial draft. Archived copy.