Archived version. This is v0.1 of the working definition, published 3 September 2026, preserved unchanged so that citations to it remain valid. The current version is v0.2. It remains available under the CC BY 4.0 licence it was published with. Several statements below were withdrawn or qualified in v0.2; read v0.2 for the current position. DELFINA is pre-launch: no signed partners or live transactions yet.

Delegated card

A payment credential funded by one party and spent by another, where each party is verified by a different licensed institution, in a different jurisdiction. This page proposes a name and a definition for an arrangement that already 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 carlo@delegated.finance.

What a delegated card is

A delegated card is a payment credential where:

1. the funds belong to a sponsor, and are charged to the sponsor's account at authorisation;
2. the credential is held and used by a recipient, who owns no balance and incurs no debt;
3. the sponsor retains authority over the credential — limits, permitted categories, suspension and revocation — after issuance and in real time;
4. the sponsor and the recipient are verified by different licensed institutions, each under the regime of its own jurisdiction;
5. and neither institution's licence alone authorises the issuance.

The first three conditions describe a supplementary card. The last two are what make it something else.

Where it sits against existing categories

Most card types differ on whose money it is. The honest comparison is with the supplementary or authorised-user card, which already answers that the same way — someone else's money, someone else's liability, someone else's rules. A delegated card is a supplementary card freed from the single-jurisdiction constraint. Two rows differ. They are the only two that matter.

Four of six rows match the supplementary card. The last two are where they diverge.

Different structure, same rules, different outcome

Naming a category changes nothing on its own. What matters is that the underlying arrangement differs, so existing rules land in different places.

No stored value the recipient owns

She holds no balance and no account of her own, so electronic-money rules attach to nothing on her side.

No debt the recipient incurs

She is a delegate spending someone else's money, not a borrower. Offshore credit origination — which generally requires authorisation in the recipient's jurisdiction — is not engaged.

One verified funding source

Not a product preference. Consumer cards for young people added relative and gift funding because families wanted it; across a border, that same feature makes the instrument openly fundable by unknown parties, which is the definition of a mule account. Restricting it to a single verified source is an anti-money-laundering control before it is anything else.

Two licences, no extension

Each institution acts only inside its own regime. Neither passports, neither sponsors the other in. The authority for the action exists only in the combination.

None of this is an exemption. The rules apply exactly as written; they simply land differently because the arrangement is different. A category name describes that. It does not claim a regulatory treatment.

What drops out, and what moves

If the recipient holds no balance, a significant amount of prepaid machinery has nothing to attach to. Less obviously, some complexity does not disappear — it relocates into the authorisation path, where it is harder rather than easier.

Drops out

• The recipient's ledger. No per-cardholder balance to maintain, reconcile or prove. An authorisation ledger still exists, but that records spending, not custody.
• Load and top-up rails. No cash-in network, no agent onboarding, no load limits, no per-load source-of-funds checks.
• Safeguarding of customer funds. E-money regimes require an issuer to safeguard relevant funds. If the recipient owns none, there is nothing on her side to safeguard.
• Dormancy, breakage and escheatment. No residual balance means no unclaimed value and no abandoned-property obligations.
• Closure and balance return. Revocation, not wind-down. Nothing has to be returned, because nothing was ever hers.

Unchanged

• Customer due diligence on the recipient. Full CDD by the local licensed institution. This is the attestation the arrangement rests on; reducing it would weaken it, not streamline it.
• Sanctions and watchlist screening, on both parties, ongoing.
• Authorisation and spend controls. The same mechanics as any controlled card.
• Settlement with the network. The issuer still settles and still carries scheme obligations.
• Statements and audit trail. Arguably heavier, since two parties need visibility rather than one.

Moves, and gets harder

• Funding sits inside the authorisation path. With stored value, an authorisation is a balance lookup — fast, local, deterministic. With just-in-time funding, the issuer must reach an external source and get an answer inside the network's response window. A real-time dependency on a third party, in the hot path, with a hard timeout.
• Availability becomes a product risk. If the funding source is unreachable, the transaction declines and someone is standing at a till. A stored-value card degrades gracefully; this does not.
• Credit exposure relocates rather than vanishing. Nobody pre-funded the transaction, so between authorisation and settlement the issuer is exposed to the funding source failing.

Less regulatory and lifecycle surface. More operational and latency surface. That is a trade, not a simplification.

What is not settled

These are unresolved. They are listed because a definition that hides its edges is not much use, and because the people best placed to answer them are more likely to reply to a specific question than to a document.

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. Crediting the sponsor's funding source requires a reverse path that may not exist, and makes the sponsor whole for a purchase the recipient may need to re-make. Holding it as a credit against the card reintroduces stored value — the exact thing the structure removes. Refusing refunds outright is unacceptable to merchants and to consumer-protection regimes. There may be an established processor practice for just-in-time programmes; if so it should be documented rather than reasoned from first principles.

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 processing when the issuer is unreachable. No funding call is made, because no call is made to anyone. With stored value the balance covers it. Here nobody has funded it, the transaction still settles, and the controls the sponsor set were never consulted. This is 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 balance is straightforward; a hold against a just-in-time funding source is not obviously the same thing — and if the final amount exceeds the hold, the second funding call may fail against controls that have since changed.

04 · Who holds the dispute right?

Scheme chargeback rules assume the cardholder and the payer are the same person. In a delegated card they are not: the recipient made the purchase, the sponsor's funds were charged. It is unclear whose consent is required to raise a dispute, whose to withdraw one, and who is made whole.

05 · What consumer protections attach to the recipient?

She is spending money she does not own, under rules set by someone else, on a credential that can be frozen without her agreement. Existing cardholder protections are written for someone whose money is at stake. What she is owed — disclosure, notice before revocation, a route to challenge a refusal — is not obvious.

06 · Is merchant-level restriction sufficient?

Category controls operate on the merchant, not the item. A card can be stopped at a liquor store but not from buying a bottle inside a supermarket. Whether that is adequate for purpose-bound programmes, or whether meaningful restriction requires point-of-sale integration, is an open question with real consequences for humanitarian use.

07 · Should the card face identify the arrangement?

Networks require product-type identification. Whether a delegated card should carry its own designation, and what appears on the credential itself, is undecided — with a real tension between transparency at the point of sale and marking the holder as a dependent in front of a cashier.

08 · What happens on the sponsor's death, insolvency or withdrawal?

The recipient's spending capacity depends on an account she does not control. There is no established practice for notice, wind-down or transition.

On the term itself

"Delegated card" is proposed as a description, not a brand. It is unowned. Categories in payments have historically been named descriptively and by adopters rather than by any single company — credit card first appeared in a nineteenth-century novel, and debit card has no clear coiner at all. 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.1. It will 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 do not need permission to take this further. Republish it, adapt it, or write a better version. If an institution, network or working group develops a definition that supersedes this one, this page will point to it rather than compete with it — the object is a shared definition, not this particular document.

carlo@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. If you improve it, publishing the improvement is encouraged.

Scope. This licence covers the text of this page. It does not licence any patent, trade mark or software. DELFINA's reconciliation architecture is the subject of a separate filing.

Cite as: Delegated card — a working definition, v0.1, delegated.finance/delegated-card

v0.1 · 3 September 2026 · Initial draft published.

This definition is maintained alongside DELFINA, a reconciliation engine that establishes the cross-jurisdictional standing a delegated card requires. DELFINA is one implementation of the arrangement described here, not the arrangement itself.