The 3rd Seat: Who Speaks for the MDB when the Vendor and the Integrator are in the Room?

Three parties sit at the governance table of every treasury or core platform program. Two arrive with a contract, a commercial team, and a defined deliverable: the vendor with account managers and product specialists, the integrator with a delivery lead and architects. The third arrives with a day job: a project manager, a treasury or operations lead, and whoever from IT has capacity for that quarter.

This is not about bad actors – vendors and integrators usually do what they are engaged to do and do it well. The problem is structural, and institutions that see it at the start run better programs than those that discover it in month nine. For MDBs and DFIs, this matters particularly because program decisions sit within formal governance, public accountability and long delivery horizons.

1. What is each party there to represent?

The vendor speaks about the product: Current capability, roadmap, configuration, fit. A good vendor will say when its product fits a requirement poorly. It will not usually say the requirement itself is questionable, or that a process change would make it disappear, which is outside its remit.

The implementation partner speaks for the build: Agreed scope, to a date, within a commercial envelope. The orientation is predictable: clear scope is good, ambiguous scope is a risk to close, growing scope is a change request. The integrator is rewarded for delivering what was specified, not for asking whether the specification reflects what the institution needs.

The institution needs someone who speaks for the MDB: For its requirements, as distinct from the specification derived from them. For its operating model after go-live. For its readiness, a people and process question, not a software one. And for its position across the contract term, not just the project.

The gap is not capability but accountability. Ask who owns, in writing, the question “is this still what we need?”, and the honest answer is often the names of several people, each of whom owns something else first.

2. What does the third seat do?

In concrete terms, the role covers five things.

1. Maintains the requirements baseline: The institution’s own statement of need behind the specification, traceable through to delivered function. When scope moves, someone must be able to say what was given up.
2. Translates between functional and commercial language: Coverage answers are also cost statements; design decisions are also contractual ones. That translation must happen before signature, and it belongs to the institution, not either counterparty.
3. Owns the operating model question: The organisation on the day after go-live: process ownership, handoffs, controls, and which manual steps disappear versus quietly persist.
4. Tests readiness honestly: Not whether the system is ready – the program plan tracks that – but whether the institution is: data, people, governance, and the capacity of a team absorbing change on top of existing work.
5. Holds the record of decisions: Including deferrals: what left in scope, who decided, at what expected cost, and when it is revisited.

None of this is adversarial. Done well, the role makes the vendor’s and integrator’s jobs easier, because ambiguity is resolved early by someone whose only interest is resolving it correctly.

3. What does this look like from the client’s side?

The institutional perspective rarely disappears in one moment. It erodes across the handovers – selection, operating model, blueprint, contract, implementation, readiness – each run by a different group that inherits a narrower version of the original question. Four patterns recur.

The requirements and the operating model must stay visible after the vendor is chosen. Selection answers which platform, not how the function will run or who owns what afterwards. Unless the future-state operating model is agreed down to named capabilities and responsible units, the vendor’s configuration becomes the operating model by default – and nobody decided that.

Test the solution end to end, not within the platform boundary. The institution’s process runs from transaction capture through settlement, accounting, and reporting, across interfaces the platform does not own. Every component can pass its own test while the chain fails on go-live weekend. Someone must be accountable for the whole of it.

Traceability must survive the phase change. Detailed requirements always exceed what a proof of concept can demonstrate – but capabilities not shown in the PoC resurface in blueprint or build unless carried forward explicitly. The institution needs an unbroken line from requirements, through what the PoC evidenced, to gaps, design decisions, and contracted scope. Break it at a handover and a known gap becomes a surprise.

Ownership, interfaces, and open items need named client-side owners before they are needed. Interfaces, reconciliation breaks, ledger boundaries and reference data each need an owner on the institution’s side, agreed before go-live. Open items need an owner and a date at every phase boundary, or they vanish when responsibility moves. And because vendor progress is easier to see than institutional readiness, the steering committee should see the two reported separately.

The vendor should speak about the product, and the implementation partner for the build. But someone still needs to speak for the institution, its requirements, its operating model, and its readiness. That client-side perspective is what keeps a program anchored to the outcome the institution set out to achieve in the first place.

 John Read, Prodktr

4. How should a buyer assess independence?

Whoever fills the seat – internal program office, dedicated function, or external adviser – the institution should have written answers to four questions.

• Any partnership, reseller, certification, or referral link to a shortlisted platform? Some add real depth, but should be disclosed before the advice, not discovered after.
• Implementation role. Would the adviser bid for, or join, the implementation that follows its own recommendation? This is the sharpest test – where the incentive runs most directly.
• Competing products. Does the adviser sell, license, or resell anything that competes with the systems being assessed?
• Commercial dependency on the outcome. Do the adviser’s fees, pipeline or partner standing depend on which option wins?

A yes is not disqualifying. The point is to know before the advice shapes the decision – and to show later that you asked.

5. Why does this matter more in public financial institutions?

Multilateral development banks (MDBs), development finance institutions (DFIs) and other public financial institutions face a sharper version of the problem, for four reasons.

1. The money is not the institution’s own. Spend answers to shareholders, member states or public funds, and “we relied on our vendor” is a weaker defence here than in a commercial bank.
2. Oversight is formal. Boards, audit, and evaluation functions will ask how a decision was reached, sometimes years later. Vendor presentations make a thin trail.
3. The procurement rules already encode the principle. Development finance treats conflict of interest as a matter of eligibility, not just disclosure: the World Bank’s Procurement Regulations for IPF Borrowers require consultants to “at all times hold the Borrower’s interest paramount, without any consideration of future work.”
4. The programs are long. Today’s platform decision will be lived with for a decade, often by people not yet in post; the requirements baseline and decision record are what survive.

That is the third seat, written as a procurement rule – one these institutions can apply to their own programs, not only to the projects they finance.

6. The seat, not the occupant

The seat can be filled by an internal program office that is senior, resourced and protected; a dedicated function, where volume justifies one; or an external adviser that passes the four questions above.

What does not work is leaving it empty and assuming the vendor and integrator will cover it between them. Each covers its own part; what is left over belongs to the institution.

Prodktr’s perspective:

The third seat is a client-side responsibility rather than a particular consulting role. The vendor represents the product, and the implementation partner the build; the institution must keep a clear view of its requirements, operating model, open decisions and true readiness – held by someone accountable across the whole lifecycle and carried through each handover, not rebuilt after it. Whether that sits internally or is supported externally, the intended business outcome stays the reference point from selection to go-live.

If that role is unclear in your program, define it before the next major decision point.

Contact us for more information.