You will know who the service depends on, and for what share.
A payment service relies on third parties. Your procurement department wants to know which ones, for what share, and what happens if one of them stops. You will find here the exact category of each type of party, the contractual allocation of responsibilities and the documents that establish it. No third party is named without a verified relationship and written authorisation.
Validated parties
Three categories, which are not merged
Naming a third party commits that third party as much as MAP. Until a relationship is verified and authorised in writing, this page describes the categories rather than citing names.
- Provider
- Performs a function on behalf of MAP, under contract. MAP remains responsible for the function towards you, and answers for the provider it has chosen.
- Technology partner
- Supplies a component or interoperability. Its role is technical and does not bind you contractually.
- Use partner
- Carries a programme with MAP. Its role is described within the programme concerned, and does not extend to the others.
These three categories are not mixed. A relationship does not change category to make a page look better stocked.
Contractual roles
Who answers for what towards you
The question that matters to your legal team is not the list of parties, but the address of a complaint. Here it is, by role.
- MAP
- Issuance of the earmarkable digital euro, application of the programme rules, checking of operations before execution, recording of every payment and reporting back to you.
- Your organisation
- Definition of the programme rules, designation of beneficiaries and of the authorised supplier categories, accountability towards its own funders.
- Operator
- Review of individual situations and day-to-day administration, where that role is distinct from the funder.
- MAP’s providers
- Technical or financial functions performed under contract, within a defined framework, with no direct contractual relationship with you.
The allocation applicable to your programme is settled at the first discussion and written into the contract. It is what determines where a request goes, and who answers for an operation.
What each technical function covers
Each technical function is identified: hosting, processing of operations, account keeping, card issuance, recording of payments on the blockchain. The location of processing is stated for each of them. These functions are described in the integration documentation, together with the authorised formats and channels.
Dependencies and unavailability
A critical dependency is a function whose interruption stops the service. It is identified together with the consequences of its unavailability and the measures planned. These elements are dealt with alongside service continuity, not at the time of the incident.
Programme contacts
While the programme is being prepared, you are given your contacts. One for day-to-day operation, one for contractual and documentary requests, and the route to follow for a complaint. These details are given by name and written into the contract. They are not published on this site.
Documents
The documents that establish this page
A document appears here once it exists and can be provided in the mode indicated.