Who, when, how much, where and what for, set before the spend.
We have the solution. Earmarking is the rules you set before the spend: who, when, how much, where and what for. They are written before the first spend and applied to every operation, before execution. Anything outside the rules is refused, with a readable reason.
The exact term: earmarking. It is the rules you set before the spend: who, when, how much, where and what for. They are checked at every operation, before it is executed.
What falls outside the framework is blocked before execution
A funder pays a budget of 600,00 € into the account of beneficiary 05, out of the 7 200,00 € envelope of the Equipment 2026 programme. Every amount and every value in this animation is an example.
Five rules are written before the spend: who, beneficiary 05; when, 1 March to 30 June; how much, 300,00 € per transaction; where, mainland France; what for, professional equipment.
A payment of 120,00 € is presented at a referenced supplier: the five rules are satisfied, the payment is accepted.
A second payment of 120,00 € is presented at a supplier outside the authorised area: the “where” rule is not satisfied, the payment is blocked before it is executed.
Benefits
What this service changes for your teams.
Control before the spend
100% of operations are checked before execution. Checking no longer happens on paperwork, once the money has gone.
Eight rules, one readable matrix
Suppliers, geographic area, period, ceilings, online payments, cash withdrawals, activation, beneficiaries: the funder reads its own frame without jargon.
Dignity for the beneficiary
A refusal is immediate and gives a reason; an authorised spend goes through like any ordinary payment. Nobody has to justify a purchase at a counter.
Example: in the Equipment 2026 programme, a technician has a €600.00 envelope. They pay €120.00 for a drill at a listed supplier. MAP checks the six rules: who, how much, when, from whom, where, how. Everything complies: the payment is accepted, the envelope drops to €480.00 and the payment is recorded on the blockchain. They then try to pay €85.00 for petrol on a Saturday. The “from whom” rule is not met: the payment is declined before it is executed, nothing is debited, and the beneficiary sees it immediately.
Example · Equipment 2026 programmeYour rules, checked before every payment.
The technician’s envelope€600.00 −€120.00 Account with IBAN, payment card
MAP checks
Who12 designated technicians
How much€600.00 per person
When1 March to 31 December
From whomListed suppliers
WhereMainland France
HowOnline yes, cash withdrawals no
DecisionWaiting for a payment
AcceptedDebited from the envelope, recorded on the blockchain0x4f2a…c19b
DeclinedSupplier not on the list. Nothing is debited; the beneficiary sees it at the till.
DrillListed supplier€120.00
Tank of petrolPetrol station, Saturday€85.00
Your rules
Six things you decide, before the first payment.
They are written before the first spend and checked at every operation, before execution. You can change them while the programme runs, under the agreed procedure.
Who
The beneficiaries enrolled in the programme, and nobody else. Instant activation of the account and the card.
Example: €600.00 per beneficiary
When
A period of use, with a start date and an end date.
Example: four months
How much
Ceilings per operation, per day, per month, or for the whole duration.
Example: €250.00 per operation
Where
A town, a department, a region, France, anywhere in the world.
Example: France
What for
The suppliers selected, by name or by category.
Example: selected suppliers
How
Online payments allowed or not, cash withdrawals allowed, capped or blocked.
Example: online yes, withdrawals blocked
Deliverables and how it works
What we put in place with you.
✓The rule matrix, written to be read by the funder.
✓The configuration of the programme and the accepted and refused test cases.
✓The reasons for refusal given back to the beneficiary and the handling of exceptions.
✓The procedure for changing the rules and the retention of the version applied.
The eight rules of a programme
Every rule is written before the first spend. It is tested on its own, then in combination, and applied to the operation as it happens.
Indicative overview. The rules adopted for a programme, their values and their exceptions are set out in its contractual documentation.
Rule
What it controls
What it does not prove
Beneficiaries
The people or organisations designated by the programme, and them alone.
The identity of the person physically presenting the card, without dedicated authentication.
Suppliers
A named, referenced supplier, or a category of merchants.
The contents of the basket or the compliance of the service invoiced by that supplier.
Geographic area
The territory from which the spend can go through.
The place where the good or the service paid for is actually consumed.
Period
The window during which operations are possible.
The right to redeem the balance, which follows its own contractual rules.
Ceilings
The maximum amount, per operation, per day or over the whole period.
The economic relevance of a spend made under the ceiling.
Online payments
The authorisation or blocking of remote payments.
The reliability of the merchant site where the payment is presented.
Cash withdrawals
The authorisation or blocking of withdrawals.
The use made of the cash when a withdrawal is authorised.
Activation
The moment the budget becomes usable, and its suspension.
The actual handing over of the card to the beneficiary or its activation by them.
Try a rule on a fictitious scenario
Choose a supplier and a ceiling, submit the operation, read the rule that explains the result.
DemonstrationIllustrative programme, fictitious data
Programme
Programme envelope€120,000Fictitious amount, set for the example.
Used and settled€84,000.00Transactions whose settlement is confirmed.
Reserved, pending€0.00Authorised, not yet settled.
Available€36,000.00Envelope less the used and reserved amounts.
Breakdown of the envelope: used, reserved, available. No negative balance is possible in the simulation.
Framework of use defined for this example
The funder has allocated the envelope to food expenditure, at the merchants it has listed, for holders enrolled in the programme, within a daily cap. These four elements make up the framework: they determine the outcome of every transaction.
Rules
Rule 1
Authorised beneficiary
Only beneficiaries enrolled in the programme have a usable balance.
Rule 2
Authorised merchant
The programme lists the accepted merchant categories.
Rule 3
Daily cap
Maximum cumulative amount of transactions over one day.
Transaction recipient
Daily cap remaining in the scenario
Transaction to submit€24.50Cap remaining: €40.00 · Available: €36,000.00
Transactions
No transaction submitted yet. Open the “Rules” tab, choose a scenario, then submit the €24.50 transaction.
Simulation log: fictitious events, of no probative value. No name, account identifier or wallet address appears in it.
Time
Amount
Recipient
Status
Reason
Action
Used €84,000.00 · Reserved €0.00 · Available €36,000.00
Educational simulation, fictitious data. It neither collects nor moves any funds, connects to no system and does not constitute the list of features offered commercially. Each rule available in a real programme is defined with your organisation and documented in the contract.
Payment declined: supplier not authorisedThe programme only authorises the merchant categories it has listed. Filtering by category does not describe the contents of the basket: it only indicates the type of recipient at which the transaction can succeed.
Transaction declined: cap reachedThe illustrative daily cap limits the cumulative amount of transactions. €40.00 remains for the day in this scenario.
Transaction declined: envelope exhaustedThe programme envelope can no longer cover this transaction. No negative balance is possible.
Transaction authorisedThe amount is reserved: it is withdrawn from the available balance but is not yet settled as used. Settlement is a second event.
Transaction settled“Authorised”, “pending” and “settled” are three distinct states: only the last one increases the programme’s amount used.
What has to be provided for explicitly
Can a refused operation be authorised afterwards?
Yes, if the programme provides for an exemption procedure: who asks for it, who grants it, on what grounds and with what trace. Without a written procedure, a refusal stays a refusal.
What happens if a supplier changes category?
The rule applies to the data available at the time of the operation. The programme must provide for who updates a supplier’s reference data, and how often.
Can the rules of a running programme be changed?
The terms of change are defined in the contract: who may request a change, its effect on operations already authorised, and the traceability of the change.
What becomes of a balance left unused at the end of a period?
The end of a period of use and the right to redeem the electronic money are two distinct questions. The treatment of balances is settled in the contract; no automatic forfeiture is presumed.
A clear framework
A precise framework, known before you sign.
The proof covers the payment: amount, supplier, date, rule applied. The rest is written here, so that nobody discovers it afterwards.
A category does not prove the contents of the basket
The rule bears on the supplier or its category, not on the items bought. Item-by-item control requires invoice line data and a specific integration, to be examined case by case.
No rule is announced before it has been tested
Every rule is tested on its own, then in combination, before being announced as available for your programme.
We do not guarantee delivery
The rule applies to the payment. It says nothing about what is delivered afterwards.
What we show before any commitment. Before any commitment, we test each rule on its own, then in combination: an authorised case, a refused case and an exception. We keep the version of the rule applied.
A worked example
A company, responsible for an equipment budget for its staff.
A company funds a piece of equipment over a given period, with selected suppliers. Purchases outside the rules are refused, under rules tested before the programme opened.
Envelope per beneficiary (example)
€600.00
Period (example)
four months
Area (example)
France
Ceiling per operation (example)
€250.00
Online payments (example)
allowed
Cash withdrawals (example)
blocked
Situation and values given as an example. No result and no price is announced.
Who, when, how much, where and what for. You choose the registered beneficiaries, the ceilings per transaction, per day or per month, the period, the authorised suppliers or categories, the geographic area. You allow online payment and cash withdrawals, or you do not. For example: €600.00 per household, at food suppliers in the chosen area, for three months.
100% of operations are checked before execution. A payment outside the rules is refused, and the reason is recorded. The beneficiary knows why straight away. Refunds and remaining balances follow the programme contract. An end date does not make the funds disappear.
No. Meal vouchers and mobility benefits each have their own regime: they do not follow from the account or the card. MAP delivers the same service as a voucher issuer: earmarked aid, a spending universe, a supplier network. And it goes further, with proof of every payment. A regulated programme is examined with you before any set-up.
What information do my teams get?
Every payment, its status and the rule applied, in real time, in the view set for each role. Authorisation and final settlement remain two distinct steps.
Tell us who funds the programme, who uses the funds and what it must allow people to pay for. We identify the rules, what you must be able to track and the points that need validation.
