How to Write a TMS RFP (Request for Proposal)

A TMS RFP (request for proposal) is the structured document you send to a shortlist of treasury management system vendors, asking each to propose — with evidence — how they meet your specific requirements, so you can compare them like-for-like. It's not the whole selection; it's one disciplined step inside it. And its real value isn't the pile of proposals that comes back. It's that writing it forces your own team to agree what actually matters before the demos start and someone falls in love with a slick screen.

I've written, scored and — more painfully — inherited a fair number of these. The good ones are short, prioritized and specific. The bad ones are a copied template three hundred lines long where every requirement is "mandatory," which is another way of saying nothing is.

Where the RFP sits

The RFP is not the start of anything. By the time you write it, two things should already be true: you know your requirements, and you have a shortlist. It slots into the wider TMS selection process like this — requirements first, then a longlist, then a way to cut that longlist down, then the RFP to the survivors.

That cutting-down step usually has a name: the RFI.

RFI vs RFP: qualify, then discriminate

An RFI (request for information) is the lighter, earlier document. You send it to a longlist to answer a simple question — who is even worth a serious conversation? Basic capabilities, company facts, rough fit, indicative cost. It qualifies vendors and turns a longlist of, say, eight or ten into a shortlist of three or four.

An RFP (request for proposal) goes to that shortlist and asks each survivor to propose in detail against your requirements. It discriminates between real contenders.

The mistake I see most often is skipping the RFI and firing a full RFP at everyone. You get twenty dense responses, your evaluation team drowns, and — because you never qualified — half of them were never realistic anyway. Qualify first. Then write a serious RFP for the few that earned one.

What a good RFP contains

The structure matters, because structure is what makes answers comparable. A workable TMS RFP has these sections:

• Company and treasury context, and objectives. Who you are, your entity/bank/currency footprint, and — crucially — the two or three problems you're actually trying to solve. Vendors write better, more honest proposals when they understand the job, not just the checklist.
• Functional requirements. The heart of it, drawn straight from your requirements checklist — cash and liquidity, bank connectivity, payments, financial risk, accounting, reporting — each already prioritized must / should / could.
• Technical, integration and connectivity requirements. How it connects to your ERP and middleware, which bank channels and message formats it supports (SWIFT, host-to-host, EBICS, API; MT940, camt, ISO 20022), and how integrations are built and maintained.
• Security and data-residency requirements. Access control, segregation of duties, encryption, certifications, and where your data physically lives and is processed — increasingly a hard constraint, not a footnote.
• Implementation and support expectations. Approach, typical timeline, resourcing on both sides, and what support actually looks like after go-live.
• Commercial and pricing questions. Licensing model, implementation cost, and the running costs that make up total cost of ownership — asked in a structured way so you can compare, not decode.
• Vendor and company questions. Viability, roadmap, reference customers, ownership. You're buying a multi-year relationship.

Write it so it actually discriminates

A structure isn't enough. Most RFPs fail not on what they ask but on how they ask it. Four habits separate an RFP that tells vendors apart from one that doesn't:

1. Prioritize every requirement — must, should, nice-to-have. If everything is mandatory, the RFP can't distinguish anyone; vendors just tick "yes" down the column and you learn nothing. The priorities are what your later scoring is weighted against.
2. Ask how, not whether. "Do you support cash forecasting?" gets a "yes" from everyone alive. "Describe how your system builds a rolling 13-week forecast, including data sources and how variance is tracked" gets you an answer you can actually judge.
3. Ask for evidence, and tie demos to your scenarios. Request examples, screenshots, reference situations — and make clear the demo will run your month-end, your payment run, your awkward intercompany case. That expectation shapes the proposals you get back, and it sets up the vendor demos and scorecard that follow.
4. Agree the scoring scheme before responses arrive. Weighted by your priorities, owned by the whole evaluation team. Decide how you'll score before you read a single answer, or the scoring quietly bends to fit the vendor you already liked.

"

The RFP's real job isn't to collect proposals. It's to force your own team to agree what actually matters — in writing, with priorities — before the demos dazzle everyone. A vague RFP produces vague, unscoreable answers, and no amount of vendor effort fixes that.

The mistakes that keep coming back

Having cleaned up after a few of these, the failure patterns are dull and repeatable:

• A wishlist with no priorities. Everything is "must," so nothing discriminates, and vendors compete on feature-count instead of fit.
• A copied generic template. It reflects some other company's process — or no company's — instead of your real requirements and your real footprint. Vendors can smell a boilerplate RFP, and they answer it with boilerplate.
• Yes/no questions. Every well-run vendor answers "yes" to a capability question. You've collected a wall of yeses and learned nothing that separates them.
• No scoring model agreed up front. Responses arrive, and the evaluation becomes a debate about how to evaluate — which is exactly when politics and the last good impression win.

The honest summary

Treat the RFP as documentation of a decision you're still making, not a form to send out and see what comes back. Its output on paper is a set of proposals; its real output is a treasury team that has argued through — and written down — what it genuinely needs, in priority order, before anyone's judgement gets clouded by a demo.

Get that right and the rest of the selection process has a spine: comparable answers, a scored shortlist, and demos that test claims instead of making them. If you're still upstream of all this and want the ground-level definition, start with what a TMS actually is — everything above assumes you already know why you're buying one.

Part of the Treasury Management Systems guide. If you found this useful, the newsletter sends one practical finance-systems pattern every two weeks — real SAP, treasury and delivery notes from 18 years inside enterprise finance.