The problem

A familiar card idea. A different arrangement across borders.

Supplementary cards and the familiar US authorized-user experience provide the starting point: one person supports another’s spending. Our proposed arrangement brings together institutions in the sponsor’s and cardholder’s countries, with a card issued locally to the recipient.

Start with the relationship

A family shares everyday expenses, or a programme supports a student. The cardholder can pay within agreed limits without asking for each purchase. Blanja and Amanah are being designed around these relationships.

Coordinate the two sides

The sponsor’s institution checks the sponsor; the recipient-side issuer checks the cardholder. DELFINA is being built to reconcile that evidence where the institutions need a shared record across jurisdictions.

Give institutions a record

The result shows who supplied each check, which configured requirements it covers and what is missing. The institutions retain their decisions and responsibilities; the result does not extend their licences.

This is a proposed two-institution arrangement, not a claim that an existing supplementary card automatically works across borders. Suitability, funding and issuance depend on the participating institutions and the corridor.

a family abroad · a parent at homea programme · the households it supportsa sponsor · a studenta spouse abroad · a partner at home

Identity-attestation reconciliation

Two signed attestations. One explainable result.

DELFINA checks the supplied evidence and regulatory scopes against the requirements configured for a corridor, identifying what is covered and what is missing. The participating institutions decide whether to proceed and remain responsible for their roles.

Authenticate and normalise
Each institution signs an attestation about the party it verified, under its own rules. DELFINA checks the signatures and maps each attestation onto a common set of requirement elements.
Evaluate combined coverage
For this corridor and this kind of card, it computes which required elements each institution’s scope covers, whether the two together cover the full set, and whether either one alone would.
Return an attributable result
Covered, or not covered with the missing elements named. Every element is traced to the institution that supplied it, so either side can check the work.
Inform the issuer’s decision
The issuing institution decides whether to issue on a covered result. The result is tied to the relationship and is re-evaluated when an attestation expires or changes.

// POST /v1/reconcile · illustrative response · worked example SG → PH
{
  "outcome": "not_covered",
  "corridor": "SG-PH.delegated_card.v1",
  "covered_by_a": ["verify_sponsor", "funding_source", "relationship"],
  "covered_by_b": [],
  "missing": [
    { "element": "verify_cardholder", "jurisdiction": "PH" },
    { "element": "issue_credential",  "jurisdiction": "PH" },
    { "element": "screening",         "jurisdiction": "PH" }
  ]
}

What “not covered” looks like when only the sponsor’s side has attested. The result names exactly what is missing and where. Field names are illustrative; the public specification link is pending verification.

Holds no moneyFunding, settlement and FX stay with licensed providers.

No raw ID documentsDesigned to evaluate signed attestations; institutions keep the verification records.

Makes no decisionThe institutions decide whether to act on a result.

Issues no cardThe licensed issuer issues and runs the card.

Not in the payment pathThere is no per-purchase authorisation step in the engine.

These are boundaries of the engine. They are not a claim that the service as a whole falls outside regulation. The legal basis for each institution’s role and its reliance on the other’s checks must be established for the selected corridor before a live pilot. Configured requirements and signed checks do not establish that legal basis by themselves.

Two flows, kept separate

Permission is checked before issuance. Payments follow their own path.

The permission flow and the money flow involve different parties. DELFINA appears in the first and not in the second.

Who checks whom

Before issuance, with renewed checks when attestations expire or relevant circumstances change.

Institution A
Verifies the sponsorA person or a programme, under A’s licence and rules. Signs the result.
Institution B
Verifies the cardholderWhere they live, under B’s licence and B’s own ID rules. Signs the result.
DELFINA
Reconciles the twoReturns covered or not covered, with each element attributed.
Institution B
Decides and issuesAs issuer of record, in the cardholder’s own name, with the sponsor’s limits.

How a purchase is paid

Every time the card is used. Proposed model.

Cardholder
PaysAt a shop terminal or an online checkout.
Institution B
Checks the paymentSponsor-set amount, period and categories, plus funding availability and issuer security checks.
Institution A
Requests funding in real timeThe proposed design requests funding as the purchase is authorised. Charge or hold timing and merchant-category information depend on the partner implementation.
Card network
Settles with the shopCross-border funding and settlement run between the licensed institutions.
DELFINA
Not involvedThe engine is never asked to approve a payment.

Worked example · Singapore to the Philippines · illustrative

An example pilot: one programme, one corridor, about a hundred cards.

One possible first pilot is an Amanah programme. Blanja could pilot first instead. Selection will weigh family or programme interest alongside an institution willing to integrate, a viable funding arrangement and a defined pilot scope. The programme example has a sponsor with a budget, a known cohort and fixed rules, giving two institutions a defined scope to evaluate. The pilot corridor is not yet fixed on either side; Singapore to the Philippines is shown as an example.

A scholarship programme supporting students at homeProposed pilot shape

Cards~100

CorridorSG → PH

Duration3–6 months

Rules5 categories

ProgrammeSponsor. Sets the limits and categories in Amanah and holds the funding account.
Institution A · SGVerifies the programme organisation and provides the funding side.
Institution B · PHVerifies each student, issues the card in their name as issuer of record, approves purchases.
DELFINAReconciles A’s and B’s attestations for each student’s relationship to the programme.
AmanahProgramme console and record: rules, approvals, reporting by period, category and person.

Singapore · Institution A → Philippines · Institution B
The first corridor in this worked example

Why a programme could pilot first

A programme gives both institutions a single sponsor to verify, a defined list of people, and spending rules agreed up front. The record it needs for its own donors is the same record the institutions can review.

Before a live pilot, the institutions would need to agree the corridor’s legal basis, evidence access and responsibilities, and test the funding arrangement with their processor. A pilot would then measure missing-evidence resolution time, issuance success, operational exceptions and reporting effort against the existing process.

The same corridor serves families

Blanja applies the same model to families supporting each other across countries. A planned waitlist will test family interest before we claim demand in a corridor. Sign-ups are not open yet.

Amanah, for programmes Blanja, for families

For participating institutions

What each role contributes, gains, integrates and keeps.

A proposed division for a first corridor, to be agreed with the institutions involved.

Role	Contributes	Gains	Integrates	Keeps responsibility for
Sponsor-side institutionInstitution A	Verification of the sponsor; the funding side of each purchase.	A way to serve customers who support people abroad, without onboarding those people itself.	Attestation signing; a real-time funding call per purchase.	Its own KYC or KYB decision, the sponsor relationship and its funding obligations.
Issuing institutionInstitution B	Verification of the cardholder; issuance and purchase authorisation.	Cardholders and programme volume funded from another country.	Attestation signing; card issuance with merchant-category limits; the funding call to A.	Issuer of record, its own compliance decisions, disputes and cardholder service.
DELFINAEngine	Reconciliation of the two attestations against corridor requirements.	Annual platform and per-reconciliation fees (proposed). Pilot pricing to be agreed.	An identity-attestation reconciliation API and SDK; corridor requirement records.	The correctness of its computation and its explanation. Not the decision.
Product layerAmanah · Blanja	The sponsor-facing experience: invitations, limits, approvals, the record.	Programme teams and families as intended product users; commercial terms to be agreed.	The institutions’ card and record interfaces.	The product experience and the accuracy of what it shows.

Before live cards: the participating institutions and their processor must assign responsibility for funding availability, authorisation time limits, settlement exposure, refunds, disputes and offline or stand-in approvals. These arrangements are unresolved; the DELFINA engine does not provide a funding rail.

The proposed DELFINA Network

Your local cardholders.
Their support, worldwide.

Explore how your institution could issue locally for people supported by families and programmes abroad—through connections on the proposed DELFINA Network.

Imagine your institution at the centreIllustrative network · No live corridors

DELFINAOverseas support. Local issuance.

Your institution · PhilippinesOne local card relationship.
More possible connections abroad.Illustrative issuing partner

Your local institutionSelected overseas connectionOther possible connections

Connections show arrangements, not payment routes.

01 Where do you issue cards?

02 Connect to support from abroad

Add an overseas sponsor market

03 Your illustrative issuing role

Explore 250 countries and territories, up to six overseas connections at a time. Selection does not establish legal suitability, participating institutions or available coverage.

Family-support context · SG → PH200,000+

Filipino community in Singapore

Reported community estimateReported 25 September 2025Philippine Department of Finance ↗

Definition and limits

The source reports more than 200,000 Filipinos in Singapore. It does not provide a reference date or detailed counting method. This community figure is not directly comparable with country-of-birth estimates.

Context for possible family relationships, not local cardholders, eligible customers or forecast card spending. Figures are not added together and do not measure programme demand.

Overseas sponsor side · SGConnect to support abroad

An institution in Singapore would verify the family or programme sponsor and provide the funding side.

DELFINA engineReconcile the signed checks

Compare the institutions’ evidence against configured requirements and identify coverage and gaps.

Your institution · PHOwn the local card relationship

As a local bank issuer in the Philippines, you would verify the recipient, decide whether to issue and provide local cardholder service.

About the estimates and map

UN DESA’s International Migrant Stock 2024 is the main source: people from the selected local market living in the overseas sponsor market, both sexes, at 1 July 2024. These are population stocks, not annual migration or payment flows. More recent national estimates and separately labelled government community reports supplement selected pairs. Their definitions and dates differ.

Missing pairs stay unavailable. A reported zero is shown as “0 reported”. Broad regional totals are not assigned to individual countries. No eligibility, adoption or spending forecast is calculated.

Adapted from UN DESA (2024), CC BY 3.0 IGO. Extracted UN data. Neither the UN nor the data providers endorse DELFINA.

Country names and approximate map positions are adapted from mledoze/countries, under the Open Database License. Adapted country catalogue. Countries and territories are listed for exploration, not as a statement of available card programmes.

The institutional opportunity

More overseas relationships.
Cards issued by you, at home.

Potential cardholders and spending

Families and programmes in different countries could support people in your market. Your institution would provide their local card relationship.

Build on each connection

Our ambition is to make joining DELFINA easier than assembling equivalent arrangements independently, through reusable API and SDK integrations and operating procedures.

Each connection needs willing counterparties and agreed legal, funding, issuance and commercial arrangements. A pilot must validate demand and economics; later connections must demonstrate reuse. No traffic, market share or exclusive access is promised. The engine stays outside purchase authorisation and settlement.

Launch partnership

Become a launch issuing partner for your market.

Start with one overseas connection, then test what can carry forward. Programme managers, processors and card networks could help establish the first deployment. In return for meaningful launch commitments, we are open to discussing limited exclusivity for a defined deployment. Scope, milestones and terms would be agreed together.

Explore an issuing partnership Opens an email draft with your selected markets. You review and send it.

What exists today

What you can inspect now, and what comes next.

A browser demonstration and a working definition are available to inspect. The demo, proposed API/SDK delivery model and live partner readiness are distinct stages.

Runs

Interactive engine demo

Signature checks, normalisation, coverage evaluation and refusals compute live. Both institutions are simulated, and cards are mock-ups.

Open the demo →

Link pending

API specification

The public specification link is being verified. The browser demo illustrates the proposed attestation exchange and reconciliation result.

Inspect the demo →

Published

Delegated card definition

A working definition of the category, open for challenge and comment, licensed CC BY 4.0.

Read the definition →

Forthcoming

Sandbox and conformance kit

A test endpoint and vectors a partner’s engineers can run against keys they generate. Not yet available.

Products on the engine

One engine. Two ways to share support.

Blanja and Amanah are two proposed applications of the same institutional infrastructure. Either may pilot first, based on user interest, institutional readiness and a workable funding arrangement.

Amanah · programme card

Programme spending, with limits and a clear record.

For aid, relief and scholarship programmes supporting people in another country. Rules set by the programme, a card in each person’s name, one record to report from.

Pilot path: programme engagementSee Amanah

Blanja · family card

Support from abroad, without the back-and-forth.

An international supplementary card experience for families: support shared expenses from abroad while your family member pays at home. Agree the boundaries once, then let everyday purchases happen within them. The proposed shared record shows purchases, not declined attempts.

Pilot path: family waitlist interestSee Blanja

Where we are

Pre-launch, with a browser demo and no live transactions.

The browser demo calculates signatures, identity comparisons and coverage using simulated institutional inputs. It demonstrates the reconciliation flow; it is not evidence of a live institutional integration. The delivery model is an API with an SDK, with partner integration and a live pilot as the next milestones.

A patent application for the architecture has been filed in Singapore. It is pending, not granted.

DoneBrowser reconciliation demoSignatures, normalisation, coverage and refusals, with simulated institutions.
DoneWorking definition publishedThe delegated card definition under CC BY 4.0. Public API specification link pending verification.
DonePatent application filed in SingaporePending examination.
NextTwo institutions, one corridorA sponsor-side and an issuing institution agreeing roles for a first Blanja or Amanah pilot.
ThenProve reuse in the next connectionAfter validating the first arrangement, measure what a subsequent institution or programme can reuse. Each connection still needs legal, commercial and operational agreement.

At a glance

Delegated Finance, in one place.

Delegated Finance is developing API and SDK infrastructure for international supplementary cards. DELFINA reconciles institutional checks; Blanja and Amanah apply the same engine to family support and programme spending.

What it does: Two licensed institutions in different countries each verify their own side and sign what they checked. DELFINA computes whether, together, they cover what a cross-border card requires, and names anything missing. The licensed issuer decides and issues the card: in the recipient’s own country, in their own name and local currency, subject to the issuer’s programme and acceptance rules.DELFINA holds no funds, receives no ID documents, makes no compliance decision and stays out of the payment path.
Who it’s for: Our intended API customers are banks and licensed card issuers. Families and programme teams are the intended users of Blanja and Amanah. Planned family sign-ups and programme discussions would test interest; institutional willingness to integrate and pay must be established separately. No demand results are claimed.
Why an institution might pay: Our hypothesis is that joining the proposed DELFINA Network could become easier than building equivalent arrangements independently. Reusable integrations, maintained corridor requirements and a consistent record of checks could reduce repeated work. A pilot must test the benefit and willingness to pay; later connections must demonstrate reuse.
Business model: Proposed: an annual platform fee plus per-reconciliation fees for participating institutions. The intended platform value includes maintaining integration patterns and corridor requirement records. Pilot pricing, the contracting party and any Blanja or Amanah product fees remain to be agreed.Platform fees and reconciliation usage are separate parts of the model. Purchase volume does not automatically generate engine fees. The proposed engine revenue model does not include a share of currency exchange. No revenue yet.
Market context: We are testing interest from families and programmes where the shops and billers they need accept cards. For broader context, the ILO estimated 167.7 million international migrants in destination-country labour forces in 2022, including unemployed people. Separately, the World Bank’s December 2024 estimate put officially recorded remittances to low- and middle-income countries at US$685 billion for 2024.These are historical context figures, not our addressable revenue. Sources: ILO · World Bank.
Corridors: The engine treats each corridor as a pair of licensing regimes, so it isn’t tied to any one country. Singapore → Philippines is the illustration used on these pages. The pilot corridor, on both sides, will be chosen with the first issuing partner.
Why now: Licensed non-bank issuers, remote digital onboarding and real-time card authorisation now exist in the markets we are designing for. DELFINA is being built to reconcile what each institution has verified against the requirements agreed for a corridor, while each retains its own responsibilities.
Defensibility: Patent application filed in Singapore, pending. Two prior-art screens across about 3,200 documents so far.A prior-art screen is not a clearance opinion. Beyond the filing, the proposed DELFINA Network would build on participating institutions, reusable integrations and accepted operating arrangements. Any advantage depends on useful participation and demonstrated reductions in implementation effort. Neither an established network advantage nor a granted patent is claimed.
Stage: Pre-launch. Browser engine demo with simulated institutions, a published working definition, and patent pending. Public API specification link pending verification. No signed partners, live transactions or revenue yet. Raising a pre-seed round; deck on request.
Team: Founder-led. Team details on request.
Contact: hello@delegated.finance

Discuss a pilot

We’re exploring a first pilot with families or a programme.

If you issue cards, hold sponsor relationships, or run a programme that supports people in another country, we’d like to hear what you would need to see.

Launch partnersCould DELFINA add a useful capability to your issuing, processing or programme offering? Let’s explore a defined launch opportunity.

Issuing institutionsWhat would you need before issuing to a cardholder you verified, funded by a sponsor outside your jurisdiction?

Sponsor-side institutionsWhich of your customers already support people abroad, and how do they do it today?

ProgrammesWhich cohort, which rules, and what your donors ask you to report.

Or write to hello@delegated.finance

Start a conversation

Tell us what you’d like to discuss about the DELFINA API and SDK, Blanja or Amanah. Include your organisation and role if relevant.

Email Delegated Finance

Opens your email app. You review and send the message there.

You can also write to hello@delegated.finance.

We use your message to respond to this enquiry. It does not subscribe you to Blanja updates or commit you to a pilot.

Keep the first message high level. Please leave out beneficiary details, identity documents and card information.

Infrastructure for international supplementary cards.