TMS RFP Template Builder

1 · Company & treasury context

Vendors write better, more honest proposals when they understand the job. Keep it short and concrete.

2 · Requirements by module

Every prompt asks the vendor to describe how — a yes/no question gets a "yes" from everyone alive. Untick what doesn't apply, edit the wording to your footprint, and keep the must-have list short: if half your requirements are must-haves, none of them are.

3 · Vendor questions

Beyond the requirements, you're buying a multi-year relationship. These probe implementation, commercials, support, roadmap and references — score the confident generalities down.

4 · Process, timeline & evaluation

Decide how you'll score before you read a single answer — or the scoring quietly bends to fit the vendor you already liked.

5 · Your RFP document

# Request for Proposal — Treasury Management System

**Issued by:** [Company name]
**Responses due:** TBC

## 1 · Introduction and instructions to vendors

[Company name] invites your proposal for a treasury management system against the requirements below. This RFP goes to a short list of vendors we consider credible for our needs; please respond to every section.

How to respond:

- For every requirement in section 3, describe **how** your system meets it today — configuration, screenshots, worked examples — not merely whether it does. A bare “compliant” will be scored as unanswered.
- Where you do not meet a requirement, say so plainly and describe the workaround or roadmap position. An honest gap scores better than a discovered one.
- Answer in the structure of this document, keeping our requirement IDs, so responses can be compared side by side.
- Shortlisted vendors will be asked to demo against **our scenarios** — our month-end, our payment run, our entity structure — not a standard script.

## 2 · Company and treasury context

| Profile | |
| --- | --- |
| Legal entities | — |
| Banks & accounts | — |
| Currencies | — |
| ERP landscape | — |
| Payment volumes | — |

What we are trying to solve:

_[The two or three problems driving this purchase — vendors write better, more honest proposals when they understand the job, not just the checklist.]_

## 3 · Requirements

**Must-have** requirements decide shortlisting — an unmet must-have needs a credible workaround to keep a proposal alive. **Nice-to-have** requirements differentiate between otherwise comparable proposals.

### 3.1 Cash visibility & positioning

| ID | Requirement | Priority |
| --- | --- | --- |
| CASH-01 | Describe how the system imports and consolidates prior-day and intraday balances and transactions from all of our banks, including any manual steps that remain. | Must-have |
| CASH-02 | Describe how a group cash position is built across our entities and currencies, and how long it takes from statement arrival to a usable position. | Must-have |
| CASH-03 | Describe how a user drills from a position number down to the underlying transactions and the source statement. | Must-have |
| CASH-04 | Describe how cash pooling structures (physical and notional; zero- and target-balancing) are represented and monitored. | Nice-to-have |
| CASH-05 | Describe how intercompany positions and internal funding are made visible alongside external bank balances. | Nice-to-have |

### 3.2 Cash flow forecasting

| ID | Requirement | Priority |
| --- | --- | --- |
| FCST-01 | Describe how a rolling 13-week forecast is built — data sources, degree of automation, and the manual inputs still required. | Must-have |
| FCST-02 | Describe how actual-vs-forecast variance is tracked, and how forecast accuracy is measured and improved over time. | Must-have |
| FCST-03 | Describe the forecast horizons and granularities supported (daily, weekly, monthly) and how a forecast rolls between them. | Nice-to-have |
| FCST-04 | Describe how forecast contributions are collected from subsidiaries or business units — workflow, deadlines and reminders. | Nice-to-have |

### 3.3 Payments

| ID | Requirement | Priority |
| --- | --- | --- |
| PAY-01 | Describe how payment approval workflows are configured — limits, four-eyes rules, and how segregation of duties is enforced rather than advised. | Must-have |
| PAY-02 | Describe how the full payment audit trail (who created, approved and released each payment, and when) is captured and exported for our auditors. | Must-have |
| PAY-03 | Describe how sanctions and compliance screening is handled — built in or integrated with a screening provider — and what happens operationally when a payment hits. | Must-have |
| PAY-04 | Describe your support for centralized payment initiation (payment factory, payments-on-behalf-of), including how entity-level controls are preserved. | Nice-to-have |
| PAY-05 | Describe how payment templates, recurring payments and bulk files are handled. | Nice-to-have |

### 3.4 Bank connectivity

| ID | Requirement | Priority |
| --- | --- | --- |
| CONN-01 | List your pre-built connectivity for our banks specifically (named in section 2), with the channel and formats supported per bank. | Must-have |
| CONN-02 | Describe the connectivity channels (SWIFT, host-to-host, EBICS, API) and message formats (MT940, camt.053, pain.001 / ISO 20022, local formats) you support for our footprint. | Must-have |
| CONN-03 | Describe the process and typical timeline for onboarding a new bank connection, and who does the work — you, the bank, or us. | Must-have |
| CONN-04 | Describe how payment status reporting (pain.002, acknowledgements) and end-to-end payment tracking are handled. | Nice-to-have |

### 3.5 Risk & hedging

| ID | Requirement | Priority |
| --- | --- | --- |
| RISK-01 | Describe how FX exposures are captured, aggregated and valued across our entities, including data collection from operations. | Must-have |
| RISK-02 | Describe deal capture and lifecycle management for the instrument types we use (FX forwards and swaps, money-market, interest-rate instruments), from capture to settlement. | Must-have |
| RISK-03 | Describe your hedge accounting support under IFRS 9 (or our applicable standard) — designation, documentation and effectiveness testing. | Nice-to-have |
| RISK-04 | Describe limit monitoring and breach alerting — counterparty, dealer and instrument limits. | Nice-to-have |
| RISK-05 | Describe how debt and investment positions are tracked — schedules, interest, maturities and covenants. | Nice-to-have |

### 3.6 Accounting & GL integration

| ID | Requirement | Priority |
| --- | --- | --- |
| ACC-01 | Describe how accounting entries are generated from treasury activity and posted to our ERP/GL (named in section 2), including how posting errors surface and are corrected. | Must-have |
| ACC-02 | Describe how the treasury sub-ledger is reconciled to the general ledger. | Must-have |
| ACC-03 | Describe period-end processing — valuations, accruals and revaluation runs — and the controls around them. | Nice-to-have |
| ACC-04 | Describe configurable controls, approvals and change logging, and how they satisfy audit and data-retention requirements. | Nice-to-have |

### 3.7 Reporting & analytics

| ID | Requirement | Priority |
| --- | --- | --- |
| REP-01 | Describe (with examples) the standard treasury dashboards — position, forecast, exposure, debt — available out of the box. | Must-have |
| REP-02 | Describe how treasury users build ad-hoc reports themselves, without vendor involvement or professional services. | Must-have |
| REP-03 | Describe data export and any feed to our BI tooling or data warehouse. | Nice-to-have |
| REP-04 | Describe how a reported number is traced back to its source transactions (provenance / drill-down). | Nice-to-have |

### 3.8 Security & administration

| ID | Requirement | Priority |
| --- | --- | --- |
| SEC-01 | Describe access control — SSO, MFA, role-based permissions — and how segregation of duties is enforced across modules, not just within payments. | Must-have |
| SEC-02 | Describe encryption in transit and at rest, and list the certifications you hold (e.g. ISO 27001, SOC 1 / SOC 2) with reports available to us under NDA. | Must-have |
| SEC-03 | Describe where our data would be hosted and processed (regions), the data-residency options, and your backup and disaster-recovery arrangements with RTO/RPO. | Must-have |
| SEC-04 | Describe user administration and the audit trail for configuration changes — who changed what, when, and how it is reviewed. | Nice-to-have |

## 4 · Vendor questions

### 4.1 Implementation

1. Walk through a typical implementation for a company of our size and footprint: phases, timeline, and who does the work — you, a partner, or us.
2. What are the most common reasons your implementations run late, and what do you do about them?
3. How is data migration handled — static data, open deals, historical balances — and by whom?
4. What resourcing do you expect from our side, by role and by phase?

### 4.2 Pricing & commercial model

1. Explain your licensing and pricing model and its drivers (users, modules, bank connections, payment volumes), with an indicative price for the footprint in section 2.
2. What one-off implementation costs should we expect, and what typically causes them to grow beyond the estimate?
3. Which running costs are NOT included in the licence — bank connection fees, SWIFT costs, test environments, upgrades, premium support tiers?
4. How has your pricing changed for existing customers over the last three years, and what contractual protection do you offer against increases?

### 4.3 Support & SLA

1. What does support look like after go-live — channels, coverage hours, escalation path, and whether we get named contacts or a pooled queue?
2. What are your SLA commitments — availability, incident response and resolution by severity — and what remedies apply when you miss them?
3. How are upgrades delivered and how often, and what work does each one create on our side?
4. Describe your incident and security-breach notification process — what we would hear, from whom, and how fast.

### 4.4 Product & roadmap

1. What is on the product roadmap for the next 18–24 months, and how do customers influence it?
2. Which parts of the product are newest or least mature, and which are in maintenance mode?
3. How do you release — frequency, opt-in versus forced, and how breaking changes are handled?

### 4.5 Company & references

1. Provide three reference customers of our size, footprint and industry we can speak to — including at least one that has been live for over two years.
2. Company facts: ownership, profitability or funding position, customer count and churn, and R&D headcount dedicated to this product.
3. Have you acquired, or been acquired, in the last five years — and what happened to the acquired products and their customers?

## 5 · Process, timeline and evaluation

- Vendor questions due: TBC
- Responses due: TBC
- Demo format: Scripted demo against our scenarios (our month-end, our payment run, our entity structure) — half a day per vendor
- Decision target: TBC

### Evaluation criteria

Responses are scored against the weights below, agreed by our evaluation team **before any response is opened**.

| Criterion | Weight |
| --- | --- |
| Functional fit | 30% |
| Bank connectivity | 20% |
| Integration | 15% |
| Implementation | 15% |
| Vendor viability | 10% |
| Total cost of ownership | 10% |
| **Total** | **100%** |

---

_Generated with the free TMS RFP Template Builder — gravam.com/tools/tms-rfp-template_