A rigorous proof of concept should test the future operating reality, not simply confirm that a platform can perform a scripted demonstration.
1. A platform decision is an operating-model decision
When a multilateral development bank replaces its treasury platform, it is rarely just choosing software. The system will carry trade capture, valuation, funding and liquidity, risk, settlement and accounting for a decade or more. It determines how many hand-offs sit between a dealer and a ledger entry, how fast a new instrument reaches the book, and how much of the control environment depends on people rather than process.
That makes selection an institutional decision with an operating-model consequence attached. Treasury, risk, operations, finance, technology and audit all inherit the outcome. A process that treats it as a feature-list comparison produces a defensible paper trail and an undefendable design.
2. Design the PoC as a decision process, not a demonstration
Most vendors are good at demonstrations: rehearsed environments, curated data and consultants who know which screens to avoid. A PoC built around vendor-led presentations adds little to what the RFP already established.
The alternative is a structured decision process the bank owns. In the PoC described here, run for a multilateral development bank after an RFP shortlist, the bank’s own experts wrote the runbooks, selected the instrument and lifecycle samples and issued them to each shortlisted provider in advance. Providers configured against the bank’s material, not their own. Sessions ran over three cycles in three weeks, load-balanced for instrument complexity and de-duplicated so nothing was tested twice for coverage optics.
Issuing scenarios in advance is sometimes resisted because it lets vendors prepare. It should be encouraged: a provider that cannot configure the bank’s own scenarios given.
3. Let the target operating model set the test scope
Scope should follow the operating model the institution intends to run, not the capability matrix the market happens to offer. Where a bank is diversifying treasury products, entering new markets or moving to a single source of trade data feeding accounting directly, those intentions are what need testing.
That work must be at least provisionally settled before scenario design begins. The bank was running an end-to-end treasury operating model programme in parallel, which gave the PoC a reference point: scenarios tested the process the bank was moving towards, not the one it was leaving behind.
4. Test the whole chain, not the front end
A platform that performs well at trade capture and poorly at accounting has not passed. Evaluation must follow instruments end to end across the functions that will use them. Testing was organised by service area – front, middle and back office, treasury accounting, risk and technology – and by instrument, spanning interest rate and cross-currency swaps, cancellable and non-deliverable structures, FX spot and forwards, and fixed income and cash.
Architecture and integration sessions are often deferred to the contract stage. That is late. Cost is driven far more by interface work, data structures and workarounds than by licence fees, and all of it is visible during a PoC if the process makes room for it.
5. Build traceability before you build scenarios
Credibility rests on an unbroken chain from requirement to decision. Each scenario was tied to a signed-off business requirement, given a test and process identifier, and mapped to its business unit and process. Named subject-matter experts scored against those identifiers; scores were consolidated into a master evaluation file and surfaced through a dashboard covering overall performance, trends by cycle, service-area performance and gap analysis down to the individual test case.
That structure earns its keep when the decision is challenged. A committee, auditor or unsuccessful bidder asking why a provider scored lower in accounting can be shown the test cases, the observations recorded against them and the function that scored them. Without traceability, an evaluation is opinion with numbers attached.
6. Agree what a score means before anyone scores
Scoring disputes are almost always definition disputes surfacing late, and they are avoidable. Before testing begins, settle the rating scale and what each point means, the evidence required, who scores which area, how scores are aggregated and weighted, and how a contested result is resolved.
This engagement used a five-point scale with defined verbal anchors and a void option where a scenario did not apply; scores were submitted per test case, timestamped and aggregated to comparable percentages. Function leads confirmed attendance, so each service-area score reflected the people accountable for it. Weekly publication stopped the analysis arriving as a single unexplained verdict at the end.
7. What the numbers will not tell you
Quantitative scoring gives a defensible basis for comparison. It does not capture what usually determines whether an implementation succeeds: workarounds presented as configuration, integration effort that only appears during design, the quality and continuity of the delivery team, the support model, and a provider’s willingness to say plainly what its product does not do.
Record those factors deliberately, as structured qualitative observations attached to the same test identifiers as the scores. Providers that give specific examples from comparable institutions, describe limitations unprompted and raise risks before being asked tend to behave the same way in delivery. Those that answer treasury questions generically, or promise everything without qualification, also deliver as they presented.
A provider with moderate scores, honest positioning and a credible integration approach can carry lower execution risk than a higher-scoring provider with a rigid delivery model. The framework should be able to express that conclusion rather than be overridden by it
8. The decision is the beginning of the work
The decision is the beginning of the work
A well-run PoC produces more than a ranking. It produces a documented view of gaps, workarounds, integration requirements and delivery risks, and that material should be carried forward rather than filed. It belongs in contractual clarification, where gaps become obligations; implementation planning, where integration work is scoped rather than discovered; design and test strategy, where PoC scenarios seed user acceptance testing; and operational readiness, where workarounds determine procedures, controls and training.
Independent client-side assurance should continue after signature. Once a provider and systems integrator are appointed, exposure shifts from selection risk to delivery risk. Assurance then means holding design decisions against the agreed operating model, testing the delivery partner’s plan and estimates rather than accepting them, and planning transition to business as usual as a change in how Treasury works rather than a go-live date.
Prodktr’s Perspective
Prodktr works with multilateral development banks and comparable financial institutions on treasury platform selection and the programmes that follow. Our consultants bring deep experience across treasury and investment operations, target operating model design, front-to-accounting integration, programme governance, complex implementations, vendor and delivery-partner management, and operational readiness and transition to business as usual.
We work on the client side of the table. If your institution is preparing a treasury platform PoC, or is midway through an implementation and wants an independent view of where it stands, we would be glad to talk.
Contact us for more information.