Selecting a Treasury platform answers the question of technology. It leaves open how the institution will operate, who owns the data and controls, and which activities sit outside the platform entirely.
1. A selection decision settles which platform an institution will use.
It does not settle how the institution will operate.
Programs take different routes from that point. Some run their own pre-scoping before contracting, working through functional, integration, migration and reporting detail so that the statement of work is written against something concrete. Others procure a formal blueprint or discovery phase within the contract. Neither route is universal. What matters is that the unresolved assumptions left by the evaluation are identified, owned, and translated into an approved delivery baseline before build accelerates.
Providers are usually candid about why this stage exists: their own methodology material tends to say that a request for proposal and a PoC are not sufficient to define the scope, budget and timeline of what follows. At selection, the delivery and commercial envelope is still open.
The risk is not that this stage happens. It is that the institution treats it as the provider’s exercise rather than its own.
2. The operating model belongs to the institution
A platform enables a large part of a Treasury operating model. It does not define it. Strategy, the current operating model, the target and the requirements that follow from them should shape both the selection and the design, and they remain the institutions to own after a provider is chosen.
Providers arrive with reference process flows, and those are useful. They are also normally drawn around the platform’s capabilities. A Treasury operating model extends beyond that boundary to include external data, downstream systems, controls, reconciliations and activities that remain outside the platform. Target processes designed only around the selected system can therefore appear complete while leaving gaps in the institution’s end-to-end service.
The operating model belongs to the institution
3. Ownership decisions are the ones that resurface
In our experience, questions left open at selection rarely disappear. They return during blueprinting, contract negotiation, design or testing, when changing scope or delivery assumptions is usually more difficult and more commercially significant.
These questions extend well beyond process ownership. The institution may still need to confirm the boundaries of the implementation scope; which products and instrument types of the platform must support, and whether that coverage has changed since the PoC; which currencies, markets, entities or portfolios are in scope; and the external systems and interfaces through which data must move. Each of these affects configuration, integrations, data requirements, controls, testing, resourcing, cost and timetable.
Ownership remains important, but it is one category among several rather than the whole of the picture. The institution still needs to decide who owns critical data, controls, reconciliations and downstream outputs, and which activities are retained internally, outsourced or brought in-house. The service delivery model must reflect the same choices, whatever mix of retained, outsourced and in-house activity results from them.
A Target Operating Model containing unresolved decisions of this kind is not yet an implementation baseline. It is a record of work still to be completed.
4. Procurement requirements must become design requirements
Requirements drafted for a tender are written to support comparison across bidders. Implementation requires greater precision: requirements must be detailed enough to configure the platform, define its interfaces, map its data, establish its controls and develop meaningful test cases and acceptance criteria. Reaching that level of detail can reveal exclusions, dependencies or enhancements that were not fully understood or priced during selection, and these are better addressed while the commercial conversation is still open than discovered after implementation begins.
5. Traceability must survive the handover
Selection produces an asset: a requirements set with criticality ratings, evaluation evidence, provider clarifications and a gap register. That asset is often owned by a team that disperses at contract signature.
A more durable arrangement is a single traceability register, owned by the institution, carrying each requirement through scoping and design decisions, configuration or enhancement, test case and acceptance, and reviewed at each stage gate. Without it, the question of why a particular item is being built becomes hard to answer within months.
6. The stage should end with a baseline
Blueprint phases commonly conclude by presenting implementation scenarios with different scope, timeline and cost. Presenting options is appropriate. Leaving the phase with options is not.
A stronger outcome is an approved implementation baseline covering scope, approach, timeline, budget, assumptions, exclusions and dependencies, supported by a controlled register recording, for every open requirement, finding and gap, whether it is resolved, formally deferred, or accepted as a risk with a named owner. Unresolved findings are likely to resurface during design, build or testing; a register ensures they resurface as known items rather than surprises.
This is demanding, cross-functional work: mapping processes the provider will not map, forcing ownership decisions across departments, and testing whether the signed-off design describes how the institution will operate. Independent support can be particularly useful where the institution needs to challenge assumptions across business, technology and provider teams.
Once that baseline exists, it must be made enforceable, which is a commercial exercise as much as a design one.
The stage should end with a baseline
7. Prodktr’s perspective
Prodktr supports institutions at this transition by connecting the selected platform back to the institution-owned Target Operating Model and challenging the assumptions that sit between selection and delivery, including scope, instrument and currency coverage, external interfaces, and ownership and service-model decisions.
By maintaining traceability from PoC evidence, requirements and gaps into an approved implementation baseline, Prodktr helps Treasury, operations, technology and procurement work from a common set of decisions before contractual and delivery commitments harden.
Contact us for more information.