Your FX risk software RFP has one job: select a platform that enforces your board-approved hedging policy, aggregates exposures in real time, supports VaR and scenario analysis, and plugs into your treasury systems. Everything else is a means to that end. Use the checklist, scoring template and sample RFP below to draft yours today.
TL;DR:
- Score proposals using weights agreed in advance: policy fit 25%, functionality 20%, integration risk and security 15% each, total cost 15%, and references 10%.
- Treat hedge ratio enforcement and audit trails as pass or fail gates, and have at least two evaluators score qualitative answers independently.
- Require separate prices for implementation, customization, migration, training, and support, then compare subscription and service costs across three to five years.
- Use a short pilot with masked or sample exposure data to verify reconciliations and confirm that a deliberately noncompliant trade is blocked.
- Bring treasury, operations, IT, procurement, compliance, and an executive sponsor into requirements gathering; share written bidder answers with every vendor.
Table of Contents
- What should your FX risk software RFP achieve?
- Which functional and technical requirements belong on the checklist?
- What integration, implementation and cost questions should you ask?
- How do you score and compare vendor proposals?
- What does a realistic procurement timeline look like?
- What should a sample RFP look like, and which questions can you copy?
- Why link the RFP to your policy and pilot before you sign?
- How can we help with your FX risk software selection?
- FAQ
- Sources
What should your FX risk software RFP achieve?
Start with objectives you can measure. "Improve FX risk management" tells a vendor nothing. "Block any trade that breaches the hedge ratios in our board-approved policy, and produce a daily exposure and VaR report without manual spreadsheets" gives vendors something to prove. Software should automate and enforce your policy, not define it, so write the policy limits into the RFP itself. If you need a starting point, our compact hedging policy template includes sample ratios.
Then draw scope boundaries. State which exposures are covered (transactional, forecast, balance sheet), which instruments must be supported (forwards, swaps, options), and whether you want software only or software plus managed services. Vendors who answer different questions produce proposals you cannot compare.
Finally, ask for governance detail. Industry treasury peer-review guidance recommends a holistic risk framework with three lines of defence and cites the FX Global Code as a control framework for corporates. Require vendors to show how audit trails, access controls and approval workflows map to that structure.
Which functional and technical requirements belong on the checklist?
Paste these into your RFP as mandatory lines, then ask vendors to mark each as standard, configurable, custom or unavailable.
- Exposure aggregation: consolidate positions across entities, currencies and systems, with position-level drilldown.
- Risk analytics: VaR, scenario and stress analysis, and hedge simulation before execution.
- Execution support: policy checks at the point of trade and links to your banking partners.
- Valuation and reporting: mark-to-market valuations for accounting and configurable board reports.
- APIs and connectors: documented REST APIs, ERP and TMS connectors, and a description of the underlying data model.
- Messaging: SWIFT and MT message support, including automated reconciliation.
- Service levels: stated latency, uptime commitments, disaster recovery and backup arrangements.
- Security and compliance: role-based access, immutable audit trails, encryption in transit and at rest, data residency options and current compliance attestations.
If your hedging approach relies on VaR, say so explicitly. Our page on hedging based on value at risk shows the kind of method detail worth asking every vendor to document.
Pro Tip: Require vendors to answer each checklist line with a short written response and a live demonstration, not just a tick in a box. A "yes" in a spreadsheet and a working feature are often very different things.
What integration, implementation and cost questions should you ask?
License fees are the visible part of the bill. Implementation and onboarding costs can add materially to the total, so make vendors price them separately from recurring subscription charges. Build a pricing template with these questions:
- Provide separate line items for implementation, customization, data migration, training and ongoing support.
- Attach a sample implementation plan with milestones and dependencies, covering ERP or TMS connections, bank onboarding and historic data preparation.
- Describe your SLAs, support model, upgrade cadence and change control process, including who approves changes to policy rules.
- Explain how your platform handles SWIFT reconciliation, margin workflows and automated notifications.
- State which of your costs are fixed, which are time and materials, and what could trigger additional charges.
Teams moving off spreadsheets should add a migration question: how will existing positions and trade history be loaded and verified? Our overview of spreadsheet FX tracking alternatives covers the practical background.
How do you score and compare vendor proposals?
Agree the weights before proposals arrive, so nobody tunes the scorecard to a favorite. A workable set of criteria:
- Policy fit (25%): can the system enforce your board-approved limits natively?
- Functionality (20%): coverage of the checklist, tested in a demo.
- Integration risk (15%): quality of the implementation plan and connector maturity.
- Security and compliance (15%): controls, attestations and audit trail depth.
- Total cost of ownership (15%): subscription plus implementation, migration and support over three to five years.
- References and stability (10%): comparable clients and the vendor's financial health.
Treat board-critical items as gates. A vendor that cannot enforce hedge ratios or produce an audit trail fails outright, regardless of its total score. For qualitative answers, define in advance what a 1, 3 and 5 look like, and have at least two evaluators score independently.
Here is a compact example with generic labels. Vendor A scores well on policy fit, moderately on integration and strongly on cost. Vendor B scores moderately on policy fit and strongly on integration and cost. Apply each score to its weight, sum the results, and compare. If the totals are close, the gates and the pilot decide, not the arithmetic.
What does a realistic procurement timeline look like?
Plan on phases that run in sequence: requirements gathering, RFP release, vendor Q&A, evaluation, pilot or proof of concept, negotiation, then implementation. Give each phase a named owner and a deadline, and leave real time for the pilot, since it is where weak claims surface.
Involve the right people early. A practitioner guide on treasury system RFPs warns that leaving out market risk, treasury back office and compliance during requirements gathering creates gaps in workflows such as margin reporting and automated SWIFT reconciliation.
- Treasury front office: owns exposure, hedging and execution requirements.
- Treasury operations: owns settlement, confirmations and reconciliation.
- IT: owns integration, security review and hosting questions.
- Procurement: owns process fairness and commercial terms.
- Compliance and internal audit: own control and evidence requirements.
- Executive sponsor: secures board sign-off.
Run Q&A in writing and share answers with all bidders. Run pilots on masked or sample data, never live bank credentials.
What should a sample RFP look like, and which questions can you copy?
Use this table of contents: objectives, instructions to bidders, functional requirements, technical and integration requirements, security and commercial terms, evaluation method, and annexes (policy extract, data samples, SLA template). Then adapt these questions:
- Show how your system blocks or flags a trade that breaches the attached hedge ratio policy.
- Provide API documentation and describe how exposures flow in from our ERP.
- Explain how you map our chart of accounts and entity structure to your data model.
- Give a week-by-week implementation timeline with customer responsibilities marked.
- Break out costs for licensing, implementation, data migration, training and support by year.
- Supply a sample SLA covering uptime, response times, incident severity levels and service credits.
- Describe how you evidence controls to auditors, including log retention periods.
Pro Tip: Ask shortlisted vendors for a short pilot focused on data integrity and control checks: load a sample of your real exposures, then verify that totals reconcile and that a deliberately breaching trade is stopped.
Why link the RFP to your policy and pilot before you sign?
My view: implementation problems can begin at the RFP stage. Teams buy features, then discover the software cannot express their policy. Anchor every requirement to the board-approved hedging policy, treat implementation cost as a material risk rather than a footnote, and insist on a short pilot before contracting. Providers that combine platform and advisory services, such as CorpHedge, can shorten the gap between policy and practice, but verify that claim for any vendor with your own data.
— Bartas
How can we help with your FX risk software selection?
We built our platform for treasury teams who want FX risk management without enterprise-scale complexity. Here is what we offer:
- Real-time exposure tracking and VaR-based hedging analysis
- Integrations with partner platforms and operational expert advice
- Advisory support for teams building their RFP and policy
Explore the product tour or our use cases, then request a demo or ask us to respond to your RFP. We are also expanding to Poland and Sweden, so teams in those markets can talk to us too.
FAQ
What is the most important requirement in an FX risk software RFP?
The software must enforce your board-approved hedging policy. Everything else, from analytics to integrations, supports that control. Write your policy limits into the RFP so vendors can demonstrate enforcement rather than describe it.
Should implementation costs be separate from license fees?
Yes. Onboarding and implementation can add materially to the total, so ask vendors to price them as separate line items. That gives you a true multi-year cost to compare.
Which stakeholders should shape the requirements?
Include treasury front office, operations, IT, procurement, compliance and an executive sponsor. A treasury RFP guide notes that leaving out market risk, back office or compliance creates workflow gaps.
Do we need a pilot before signing?
A short pilot is strongly advisable. Test data integrity and control checks using your own exposures, and confirm that a policy-breaching trade is blocked.
Does the FX Global Code apply to software selection?
It is a useful reference for governance and conduct rather than a software standard. Industry guidance cites it as a control framework for corporates, so ask vendors how their controls support it.