Article map
Treasury Management System selection often begins with a long spreadsheet of features and ends with vendor demonstrations that follow prepared product scripts. This can create false equivalence: every vendor marks most requirements as available, while the committee gains little evidence about workflow depth, data lineage, exception handling, control or implementation effort.
A better selection process is scenario-led and evidence-based. It defines the treasury operating outcomes, separates mandatory capability from preference, tests material workflows using realistic data, evaluates architecture and control, and scores implementation credibility and total cost alongside product functionality.
This article provides a practical scorecard that potential buyers can use to structure an RFP, demonstration, proof of capability and final decision.
1. Define outcomes, scope and decision principles
The selection should start with the problems the organisation intends to solve and the scope it can realistically implement. This gives the committee a basis for weighting requirements and challenging attractive but irrelevant features.
The operating boundary should define:
- entities, banks, currencies, users and transaction scale
- cash, forecast, payment, debt, investment, FX, reconciliation and reporting priorities
- control, audit, security and resilience objectives
- integration, hosting, data-residency and deployment constraints
- phasing, budget, target date and success measures
Decision principles should state whether standardisation, configurability, rapid deployment, depth, extensibility or particular hosting constraints carry greater importance.
2. Build requirements around business scenarios
Requirements should describe the event, user, input, decision, control, exception and output rather than ask whether a generic module exists.
The governed data record should capture:
- daily cash position with missing bank feed and restricted cash
- thirteen-week forecast with business submission and downside scenario
- payment with beneficiary change, rejection and repair
- debt maturity with covenant and refinancing trigger
- FX exposure, hedge approval, valuation, settlement and accounting evidence
Scenario wording exposes integration among capabilities. A feature may exist but fail to support the end-to-end operating chain.
3. Score evidence, not vendor assertion
The response scale should distinguish standard production capability, configuration, extension, roadmap and non-availability. Demonstrations and documentation should substantiate material claims.
The end-to-end workflow should make visible:
- live standard capability shown in the proposed version
- configuration requiring defined effort
- custom development, partner component or manual workaround
- committed roadmap with date and contract treatment
- not available or outside proposed scope
A “yes” with extensive custom work is not equivalent to standard capability. Commercial and delivery scores should reflect the difference.
4. Evaluate architecture, control and non-functional fit
Treasury value depends on data, security, availability, performance, change and auditability as well as screens. Non-functional requirements should be tested in the context of actual operating volumes and risk.
The control architecture should address:
- integration patterns, APIs, files, events and canonical model
- identity, access, segregation, privileged control and audit trail
- availability, recovery, monitoring and support
- performance, scalability, localisation and data retention
- configuration governance, release management and testing
Security questionnaires should be supplemented by architecture discussion and evidence relevant to the proposed deployment model.
5. Test the implementation and operating model
The platform can be suitable while the proposed implementation is not. Buyers should evaluate data migration, bank onboarding, design governance, testing, cutover, training, support and dependency on scarce specialists.
The TMS configuration should support:
- delivery methodology, roles and decision forums
- implementation team experience and continuity
- bank, ERP and market-data onboarding approach
- test, cutover, hypercare and rollback model
- post-go-live support, enhancement and knowledge transfer
Reference calls should explore what required more effort than expected, how defects were resolved and whether the operating team became self-sufficient.
6. Compare total cost and commercial flexibility
Pricing should be normalised across licence or subscription, users, modules, entities, environments, data, interfaces, implementation and future change. Low entry cost can be offset by restrictive expansion economics.
Management reporting should measure:
- software and environment cost over the evaluation horizon
- implementation, integration, data and bank charges
- mandatory third-party products and services
- support, upgrade, storage and transaction-volume cost
- growth, exit, data extraction and contract-change terms
The decision should include cost of retained manual processes and gaps, not only vendor invoice value.
7. Run governance that protects comparability
A selection committee needs controlled questions, demonstrations, scoring, conflict declarations and decision evidence. Vendors should receive the same core scenarios while retaining room to demonstrate differentiated value.
The implementation plan should sequence:
- independent scoring before consensus discussion
- weighting agreed before final demonstrations
- evidence log and clarification register
- normalisation of assumptions and exclusions
- documented recommendation, residual gaps and negotiation conditions
Consensus should not erase score divergence without understanding it. Different scores can reveal materially different interpretations of the same requirement.
Management questions before approval
Before management approves treasury management system selection, the discussion should test the boundary described by define outcomes, scope and decision principles, the reliability of daily cash position with missing bank feed and restricted cash, and whether integration patterns, APIs, files, events and canonical model remains effective when an exception occurs. It should also ask how software and environment cost over the evaluation horizon will reveal whether the decision delivered its intended treasury result.
- Are operating outcomes defined before the RFP?
- Are requirements scenario-based and weighted?
- Does scoring distinguish standard, configured and custom?
- Are material claims demonstrated with evidence?
- Are exceptions and controls included in scenarios?
- Is architecture evaluated for the proposed deployment?
The TMS record should connect those answers to score evidence, not vendor assertion and to the action 'independent scoring before consensus discussion'. Where judgement changes the normal route for treasury management system selection, the evidence, approver, effective date and next review should remain visible beside delivery methodology, roles and decision forums.
Evidence a controlled TMS should retain
The operating record for selecting a treasury management system should show how daily cash position with missing bank feed and restricted cash became an approved action under evaluate architecture, control and non-functional fit. It should retain source identity, calculation or transformation, workflow status, exception treatment and approval, together with the downstream result represented by delivery methodology, roles and decision forums.
- integration patterns, APIs, files, events and canonical model
- identity, access, segregation, privileged control and audit trail
- availability, recovery, monitoring and support
- delivery methodology, roles and decision forums
- implementation team experience and continuity
- bank, ERP and market-data onboarding approach
Version history for daily cash position with missing bank feed and restricted cash should preserve the information used when the decision was taken, even if later correction changes the current view. Comparing that history with software and environment cost over the evaluation horizon and the practical outcome in 'two vendors with the same feature score and different operating fit' allows management to evaluate process discipline and decision quality without hindsight rewriting.
Operating decision record
The decision record for treasury management system selection should identify the event, the data cut supporting build requirements around business scenarios, the assumptions applied and the policy or mandate that governed the choice. It should compare the selected action with a realistic alternative, identify the accountable owner and approver, and state when 'documented recommendation, residual gaps and negotiation conditions' or another change will require reassessment. A decision not to proceed with 'independent scoring before consensus discussion' should document the tolerance relied upon with the same discipline as an executed treasury action.
Continuity depends on linking that conclusion to post-go-live support, enhancement and knowledge transfer and to later evidence of growth, exit, data extraction and contract-change terms. Reviewers can then distinguish whether the original decision was reasonable on the information available from whether the eventual outcome in 'two vendors with the same feature score and different operating fit' happened to be favourable or adverse.
Review cadence and change triggers
Routine review of treasury management system selection should follow the cadence implied by live standard capability shown in the proposed version, while an immediate refresh should occur when FX exposure, hedge approval, valuation, settlement and accounting evidence, phasing, budget, target date and success measures or a material system configuration changes. The reviewer should compare the current position with the last approved analysis and test whether configuration governance, release management and testing and related limits remain valid.
A trigger may confirm that the existing define outcomes, scope and decision principles design remains suitable; it does not always require a new transaction or configuration change. Continued reliance should nevertheless become a dated conclusion, supported by implementation team experience and continuity and reported through implementation, integration, data and bank charges. Any treasury management system selection exception should carry an owner, interim treatment, escalation point and evidence of closure within the same TMS process.
Practical illustration: two vendors with the same feature score and different operating fit
Two TMS vendors both score ninety per cent on an RFP. In a scenario-led demonstration, one processes a rejected cross-border payment through status ingestion, repair, renewed approval and reconciliation. The other shows payment initiation and a separate exception screen but requires manual status upload and an external workflow for repair.
The scorecard reclassifies the second response from standard capability to custom integration and workaround. Total cost includes the additional component and operating effort. Reference calls confirm that similar integrations extended prior projects.
The final decision is based on evidence of the complete process rather than the identical “yes” entered against a broad payment-exception requirement.
Implementation checklist
A treasury team preparing to operationalise this topic should be able to answer yes to the following questions:
- Are operating outcomes defined before the RFP?
- Are requirements scenario-based and weighted?
- Does scoring distinguish standard, configured and custom?
- Are material claims demonstrated with evidence?
- Are exceptions and controls included in scenarios?
- Is architecture evaluated for the proposed deployment?
- Is implementation team quality scored separately?
- Are reference calls structured around delivery reality?
- Is total cost normalised over the same horizon?
- Are residual gaps and assumptions documented in the recommendation?
Common design failures
TMS selections fail when feature quantity, presentation quality or lowest quoted cost substitutes for evidence of operating fit and implementation feasibility.
- issuing an exhaustive unweighted feature list
- allowing vendors to define every demonstration scenario
- scoring roadmap and production capability equally
- evaluating screens without data, exception and control flow
- ignoring implementation partner and bank-onboarding capability
- comparing licence price without integration, change and retained manual cost
A robust selection process makes vendor claims comparable, reveals where value depends on custom effort and preserves the reasons behind the final choice.
Closing perspective
Selecting a TMS is a decision about the future treasury operating model. Product functionality matters, but so do architecture, control, implementation, adoption and commercial flexibility.
A scenario-led scorecard allows a potential client to assess Vilfora and other platforms against the complete treasury outcomes that will determine value after go-live.
Frequently asked questions
How many TMS requirements should an RFP contain?
There is no ideal number. Prioritise clear, weighted requirements tied to material business scenarios rather than maximising line count. Detail should be sufficient to distinguish operating fit.
What should a TMS demonstration include?
Use realistic end-to-end scenarios with source data, workflow, controls, exceptions, bank or external feedback, accounting, reporting and drill-down evidence—not only preconfigured dashboards.
How should customisation be scored in TMS selection?
Distinguish standard configuration from extension, custom development and manual workaround, then score delivery risk, support, upgrade impact, cost and operating dependency explicitly.