Proof nobody can rewrite, with a scope that is spelled out.
We have the solution. Every payment is recorded, and nobody can change it afterwards, neither MAP nor the funder. That record sits on a tamper-proof blockchain. The proof covers the payment: amount, supplier, date, rule applied.
The exact term: a blockchain. Every accepted payment is recorded in a chained ledger: each entry locks the previous one, so nothing can be rewritten afterwards. The proof covers the payment, not the contents of the basket.
A payment of 120,00 € is made at a referenced supplier, on 12/10/2026 at 12:04.
The payment is sealed: it becomes block 145, carrying the fingerprint 4f2a…c19b.
The block joins a chain of five blocks, where every block locks the one before.
Changing the amount to 480,00 € breaks the seal and the link: the chain rejects the change, then the original record is restored.
Benefits
What this service changes for your teams.
Proof nobody can rewrite
The history is unalterable and any retroactive change is detectable. Where payment vouchers and prepaid cards produce an internal report, MAP provides the proof.
Each party sees what concerns it
Views are defined by role and by purpose. A funder can account for its programme without access to other beneficiaries’ files.
A scope that is explained, not a slogan
We write down what the trace proves and what it does not. That is the condition for internal audit to rely on it.
Your rules
What we set with you, before the first entry.
The core is the same for every programme. What varies from one programme to the next is set with your teams, before the first spend.
What is recorded, what stays off chain
The events recorded on the chain and the data kept off chain.
Example: a payment of €600.00, the supplier, the date, the rule applied
The network and access
The network adopted, the actors that validate the entries and the access rights.
Example: one view per role: funder, operator, audit
Verification and corrections
The verification method, reproducible by an authorised third party, and the handling of corrections.
Example: reproducible by an authorised third party
Integration with your systems
The integration of the proof into your existing system, run with your teams rather than self-service.
Example: run with your teams
Deliverables and how it works
What we put in place with you.
✓The history and the views fitted to the roles of the programme.
✓What the proof covers and the verification method, explained in writing.
✓The handling of corrections and the separation of on-chain and off-chain data.
What the ledger proves
✓An unalterable history of entries, in which any retroactive change is detectable.
✓An order and a time stamp common to all recorded entries.
✓The payment itself, through to the supplier: amount, supplier, date, rule applied.
✓A shared read for authorised parties, with no manual reconstruction.
What it does not establish
×The contents of the basket or the delivery: the proof covers the payment, not what was bought item by item.
×The truthfulness of data entered: a faithful entry can record false information.
×The absence of fraud, which depends on onboarding and monitoring controls.
×The social impact of a programme, which belongs to its evaluation and not to the ledger.
The ledger does not issue the funds
Electronic money is euros issued against the euros received, one for one. Its issuance therefore rests on the funds received. The ledger’s entries reflect operations; they do not create monetary value.
Governance and access
A ledger raises questions of governance. Which network, which actors validate the entries, who has access to what. Which data are recorded on the chain, and which stay off chain. The answers that apply to MAP’s programme are published with the service’s technical documentation.
Articulation with financial systems
The ledger is one component among others. The funds received, their safeguarding, payment operations and the institution’s obligations fall under the applicable financial rules. The ledger technology does not change this articulation.
Legal characterisation
Legal characterisation, that is what an instrument is in law, is examined on the actual product. MAP publishes no general conclusion by reason of the use of a blockchain alone.
Personal data and the ledger
No personal data are made public on the chain. The treatment adopted is described on the Personal data page, with the distinction between data recorded on the chain and data kept off chain.
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.
The trace proves the payment, not the basket
A payment trace proves neither the contents of the basket, nor delivery, nor social impact, nor general compliance.
Verification is demonstrated on your programme
Independent verification and the architecture of the product sold must be demonstrated on your programme.
No personal data on the chain
No personal data are made public on the chain. The identity of beneficiaries stays off chain.
What we show before any commitment. Before any commitment, we start from a real payment we are authorised to show. We find its record and any correction to it, then an authorised third party reproduces the verification.
A worked example
An internal audit team, or the funder of a co-funded programme.
The funders of a co-funded programme consult the information they are authorised to see and verify the integrity of the records covered, without access to other beneficiaries’ data.
What is recorded (example)
a payment of €600.00, the supplier, the date, the rule applied
What stays off chain
the personal data of beneficiaries
Verification
reproducible by an authorised third party
Views
one per role: funder, operator, audit
Scope of the proof
the payment, through to the supplier
Situation and values given as an example. No result and no price is announced.
Every payment is recorded on a tamper-proof blockchain: the amount, the supplier, the date and the rule applied. Nobody can change that record afterwards, neither MAP nor the funder. The proof covers the payment. It does not say what was in the basket, nor whether the goods were delivered. No personal data is written to the chain.
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.
No. Each role sees what concerns it, and nothing more. A funder follows the payments of its own programme in real time. It has access neither to beneficiaries’ personal data nor to their files.
An earmarked payment accepted, then a payment refused. What each role sees in both cases, and the record written to the blockchain. The demonstration draws on the Mes Potos solidarity programme, documented with what it covers, and is set around your own programme.
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.
