What makes procurement transformation in banking different?
In most companies, a procurement transformation is about cost, process and tools. In a bank, a second reader looks at the result: the supervisor. Many contracts that procurement negotiates fall under rules on ICT services or on outsourcing. The bank must list them in registers, check the supplier before signing, put required clauses in the contract and plan how it would exit.
So the questions change. It is not only “how fast do we approve a request?”. It is also “when an IT team asks for a new cloud tool, who decides whether it supports a critical function, and where is that answer stored?”. If the answer lives in an email, someone rebuilds the register by hand every year.
The same applies across financial services: two insurers, Hiscox and Covéa, mention DORA in their Ivalua case studies. This page covers EU and UK banking rules. It is a reading of the official texts, not legal advice. Your compliance and legal teams decide how each contract is classified.
Which rules reach the procurement process in a bank?
Four sets of texts matter for an EU or UK bank. The middle column says what each text asks. The last column is my reading of where it lands in procurement.
| Rule | What the text asks | Where it lands in procurement (my reading) |
|---|---|---|
| DORA, Regulation (EU) 2022/2554, applies since 17 January 2025: the register | Art. 28(3): a register of information on all contracts for ICT services from third-party providers, per entity and for the group, separating those that support critical or important functions. Information from it reported to the supervisor at least yearly; the full register on request | Every ICT contract, whoever buys it, needs the same fields: provider, service, function supported, criticality |
| DORA: before signing | Art. 28(4): assess whether the service supports a critical or important function, the risks including concentration, due diligence on the provider, conflicts of interest. Art. 29: account for providers that are not easily substitutable | A classification and due diligence step before the contract is awarded, not after it is signed |
| DORA: contract clauses | Art. 30(2), all ICT contracts: full description of the service, where data is processed, access to and return of data at the end, service levels, termination rights. Art. 30(3), critical or important functions: also unrestricted access and audit rights, and exit strategies with a mandatory transition period | A clause library, and a check that the clauses are in the signed contract |
| DORA: exit | Art. 28(8): exit strategies for ICT services that support critical or important functions, with exit plans that are documented and tested | An exit plan attached to each critical contract, with a review date |
| EBA Guidelines on outsourcing arrangements (EBA/GL/2019/02) | A register of all outsourcing arrangements, with dates, function, provider (including its LEI and country), data location, critical or important yes or no, and the date of the last assessment. Sent to the supervisor on request, in a format such as CSV. A documented exit strategy for critical or important outsourcing | Supplier and contract fields that can be exported, not typed again into a spreadsheet |
| EBA Guidelines on third-party risk for non-ICT services, published 18 September 2026 | Will repeal the outsourcing guidelines once they apply. They cover non-ICT services; ICT services fall under DORA. The EBA page gives no application date yet | The outsourcing register will change again: keep its fields in one place |
| UK: PRA SS2/21, in force since 31 March 2022 | An outsourcing register, expected from banks since 31 December 2021. Materiality and risk assessed for all third-party arrangements, not only outsourcing. Stressed and non-stressed exit plans for material outsourcing | The same steps for UK entities, with UK definitions |
| UK: PRA PS7/26, published 18 March 2026 | From 18 March 2027: notify the PRA before entering into or significantly changing a material third-party arrangement (a notification, not an approval), and send an annual register of these arrangements | Notification becomes a step in the procurement timeline, before signature |
None of these texts mentions procurement software. They ask for data, checks and clauses that procurement already handles, and they ask for them every year.
The registers are not a formality. In the Netherlands, the central bank DNB asked for the DORA register by 20 March 2026, with 31 December 2025 as the reference date, and repeats the exercise every March. In November 2025, the European supervisory authorities used data from these registers to designate the first critical ICT third-party providers.
Is the procurement platform itself an ICT service under DORA?
Probably, but the bank decides. DORA defines ICT services as “digital and data services provided through ICT systems to one or more internal or external users on an ongoing basis”. A source-to-pay suite bought as a cloud service seems to fit that definition. That is my reading, not a statement by a supervisor. If it is right, the contract with the vendor goes into the register of information and needs the clauses of Article 30(2).
Whether it supports a critical or important function is a separate question. DORA calls a function critical or important when its disruption “would materially impair” the financial performance of the entity or the continuity of its services. Each bank makes that assessment for itself.
The larger effect is elsewhere. The procurement process handles the contracts of many other ICT providers: cloud hosting, banking software, IT support. For most of them, procurement is where the data the register needs is first collected.
What changes in the procurement platform?
Each requirement becomes a field, a question, a step or a report in the source-to-pay platform. The table follows a purchase from request to exit. It is my reading of the texts above, based on how platforms such as Ivalua are configured. It does not describe any one bank.
| Step | What the rules need | What it becomes in the platform |
|---|---|---|
| Request | Know early whether the purchase is an ICT service, an outsourcing arrangement or neither, and whether it may support a critical function | Mandatory questions in the request form, with routing to risk or IT when the answer is yes |
| Supplier record | Legal entity identifier (LEI), registered address, parent company, country where the service is performed, data location | Mandatory fields on the supplier record, checked before the supplier can be used |
| Before award | Due diligence, risk and concentration assessment, conflicts of interest | A questionnaire and an approval step that must be complete before the contract is awarded |
| Contract | The clauses of DORA Article 30, and the EBA minimum content for critical outsourcing | Contract templates with the clauses, and a field that records which clauses were kept |
| Register | A register per entity and for the group: DORA information reported at least yearly, the EBA register sent on request in a format such as CSV | A report built from platform data, the same every year, not a spreadsheet rebuilt by hand |
| Review | The date of the last criticality assessment, and regular review | A review date on each contract, with a reminder to its owner |
| Exit | Documented and tested exit plans for critical services | The exit plan attached to the contract, with the date of its last test |
Most of this is configuration: fields, questionnaires, workflow steps and reports. The hard part is agreeing the definitions with compliance before anyone configures them.
Two cautions from Ivalua projects. Banks have many entities, and an approval rule built for one entity only still has to be retested at every upgrade: keep the regulatory steps common to the group where the rules are common. And a register built from platform data is only as good as that data: the same supplier created three times becomes three lines in the register.
Some banks say this openly. When Crelan, a Belgian cooperative bank, chose Ivalua for its whole source-to-contract process in 2021, Ivalua’s release said the aim was to remain “EBA and NBB compliant throughout every step of the Sourcing and Supplier Relationship Management journey”. That is the vendor’s release, not an audit.
Which banks run procurement on a source-to-pay platform?
Banks rarely publish case studies, but their supplier pages tell suppliers which platform to use. These are public statements, read in October 2026.
| Bank | Platform | What the bank or the vendor says |
|---|---|---|
| BNP Paribas Fortis (Belgium) | Ivalua | Agreements with suppliers are signed electronically with DocuSign “within the OneProcTool/Ivalua platform (communication platform between BNP Paribas Fortis and suppliers)” (supplier page) |
| Danske Bank (Denmark) | Ivalua | Ivalua is “our main tool for supplier management, sourcing and contract information exchange”; source-to-contract functions enabled since 23 November 2020, ordering and invoicing “at a later stage” (supplier page) |
| Crelan (Belgium) | Ivalua | The whole source-to-contract process, delivery led by KPMG Belgium with Ivalua’s services (Ivalua release, October 2021) |
| Bendigo and Adelaide Bank (Australia) | Coupa | Launched in May 2025; invoices go through the Coupa Supplier Portal and must reference a valid purchase order (supplier page) |
Danske Bank and Crelan started with suppliers, sourcing and contracts. That order also puts the register’s raw data, suppliers and contracts, in the platform first.
What did I do on BNP Paribas’s source-to-pay platform?
I have worked on three full-cycle Ivalua implementations on BNP Paribas’s source-to-pay platform: two between 2020 and 2023, and the third since July 2025. Each case study gives the detail.
- [v156](/case-studies/bnp-paribas-ivalua-v156): we built and deployed the group’s source-to-pay platform, with suppliers, sourcing, contracts, catalogue, workflows and e-procurement. It carried many complex specific configurations.
- [v164](/case-studies/bnp-paribas-ivalua-v164): a complete redesign, built from scratch. It simplified the specific configurations of v156 and redesigned the workflows. v156 and v164 were delivered on budget and on schedule. I led a mixed team of 15 on v156 and v164.
- [v182](/case-studies/bnp-paribas-ivalua-v182): a new solution, also built from scratch, delivered and still evolving. The old and new versions run in parallel while all entities and users switch over step by step. The go-live was on schedule.
My work there is the platform: design, configuration, supplier and ERP interfaces, data flows, advanced SQL for reports and controls, data migration, and change management when entities moved to the platform, in France and abroad. The case studies do not describe the bank’s regulatory registers. The regulatory sections of this page come from the official texts, not from BNP Paribas.
Before Ivalua, I worked on IT projects in banking. At Crédit Agricole CIB (2011–2014), I worked on a SaaS product for Basel II and III compliance, with LCR and NSFR liquidity reports. At Société Générale (2014–2020), I delivered Rapsody, a SaaS platform that calculates the profitability of international subsidiaries, rolled out to 20 entities worldwide, and worked on regulatory reporting for liquidity and risk.
How can I help a bank with its procurement transformation?
On the Ivalua part, as a senior consultant inside your team. Typical situations in a bank:
- Your compliance team has defined what the DORA or outsourcing register needs, and nobody has yet turned it into fields, questions, approval steps and reports in the platform.
- A rebuild or an upgrade is planned, and you must decide which entity-specific rules to keep.
- Group entities move to the platform one after another, and each move needs its interfaces, data and training ready on time.
| Service | What it is | Duration | Price |
|---|---|---|---|
| Senior mission | Techno-functional lead or programme manager inside your team | Custom | Day rate, on request |
| An Ivalua team I lead | Certified consultants from my network, with me as the single lead | Custom | Day rate per consultant, on request |
| Ivalua health check | Each area of the platform rated, with a 90-day plan | 3 weeks | From €12,500, fixed price |
A mission or a team to do the work; a health check when you first need to know what the platform can carry.
I do not classify your contracts under DORA or write your compliance policy: that is the work of your compliance and legal teams. I make the platform carry their decisions. For the wider programme, read What is procurement transformation?. To discuss your project, book a call or write to me.
Frequently asked questions
Short answers to the questions people ask, each one sourced above.
Does DORA apply to procurement?
Not to procurement as a department, but to many contracts it handles. DORA asks financial entities to keep a register of all contracts for ICT services, to assess providers before signing, to include required clauses and, for critical or important functions, to plan exits. Much of that data is first collected during the procurement process.
What is the DORA register of information?
It is a register, kept per entity and for the group, of all contracts for ICT services from third-party providers, showing which ones support critical or important functions. Banks report information from it to their supervisor at least yearly, and give the full register on request. In the Netherlands, DNB set 20 March 2026 as the deadline, with 31 December 2025 as the reference date.
Is the DORA register the same as the EBA outsourcing register?
No. The DORA register covers contracts for ICT services. The register in the EBA outsourcing guidelines (EBA/GL/2019/02) covers outsourcing arrangements, and the two can overlap for ICT outsourcing. On 18 September 2026 the EBA published new guidelines on non-ICT third-party risk, which will replace the outsourcing guidelines once they apply.
What does procurement transformation in financial services add to a standard programme?
A regulatory layer. Besides cost, process and tools, the programme must make the procurement process produce what supervisors ask for: a classification of each contract, due diligence before signing, required contract clauses, registers and exit plans. In practice, that means fields, questionnaires, approval steps and reports in the source-to-pay platform.
Project already started? Check where it stands.
The health check scores your platform and your programme in three weeks.
Seb Troz
Certified Ivalua consultant (L1–L3). Three full-cycle implementations at BNP Paribas (v156, v164, v182), programme manager at Vallourec. Led a team of 13 on Rapsody at Société Générale. Engineer, ENSIMAG. About Seb