Back to Blog
The FX Market Data RFP Evaluation Checklist (2026 Edition)

The FX Market Data RFP Evaluation Checklist (2026 Edition)

Five pass/fail gates and a 10-category, 100-point scorecard for choosing an FX data provider. Written for cloud workloads, DORA rules, and the growing number of data users that are software rather than people.

Summary. When your firm buys a feed of currency prices, run the selection in two stages. First, five simple pass/fail checks: written answers, published figures on how many prices were delivered, speed figures given as percentiles, the DORA contract pack, and a written policy on API changes. Second, a 100-point scorecard across ten areas, weighted toward speed from the cloud, data quality and resilience. A vendor needs 70 points to earn a 48-hour trial. The framework and the free Excel scorecard come from TraderMade, an FX data provider that has answered these questions from the vendor side for over a decade.


Most FX data RFPs and procurement reviews ask two things: what does it cost, and do you cover the currency pairs we need. Every vendor says yes to the second, and the price is the smallest part of what the feed will really cost over three years.

FX is harder to buy than most data. Shares trade on exchanges, so there is one official record of every price. Currencies do not. They trade between banks and electronic venues all over the world, and there is no single tape. Every vendor's EUR/USD price is a blend of whichever banks and venues that vendor listens to, cleaned up by rules the vendor wrote. Two feeds can both be "live" and still disagree by a pip (the smallest normal price move, 0.0001 on EUR/USD) for minutes at a time. Your RFP has to find out what is behind the price, because nothing else will tell you.

Three things have changed since most RFP templates were written:

  1. DORA. An EU law (Regulation (EU) 2022/2554) that, since January 2025, makes banks and other financial firms responsible for the IT risk of their suppliers, with specific terms that must be in every contract.
  2. The cloud. Trading systems now run in cloud regions like AWS London or Frankfurt. A speed figure measured in a data centre where servers sit next to the exchange (co-location, such as LD4 in London) tells a cloud user nothing.
  3. Software as the customer. Trading programs, AI models and MCP agents (a standard that lets AI tools connect to data services) now read more prices than people do.

The framework runs in two stages. Stage 1 is five gates: pass or fail, answered in writing, before your engineers spend any time. Stage 2 is a 100-point scorecard for the vendors that get through. A vendor can score brilliantly and still be one you are not allowed to sign with, which is why the gates come first.

Use it in your next vendor review. The Excel workbook has the gates, every criterion with its points, selectable weighting profiles, a comparison tab and a trial log. It is free, in two editions. Download the FX market data RFP template (Excel): Standard edition or EU / DORA edition.


Stage 1: The Gates

The gates are deliberately easy. They do not test whether a vendor is good. They test whether a vendor behaves like a supplier to regulated firms. A vendor that fails one is set aside until it can pass.

Gate What you ask for What passes
G1: Written answers Every question answered in writing A sales demo is fine as an extra. A vendor that will only answer out loud has decided what you are allowed to check.
G2: Tick transparency Published figures on how many price updates (ticks) were delivered Figures for the five busiest pairs over the last 30 days, defined as ticks delivered to clients divided by ticks the vendor accepted into its feed, ideally with a count of ticks the vendor's quality filters rejected and why.
G3: Speed as percentiles Latency (the delay between a price changing and you receiving it) as p50, p95 and p99 p99 means 99 out of 100 updates arrived within that time. An "average" or an "up to X ms" figure on its own means the vendor has not measured under pressure.
G4: DORA contract pack The Article 30 terms, in writing A promise to tell you about incidents within a set number of hours, the right to audit the vendor, a list of the companies the vendor itself depends on (sub-processors), and help if you ever leave. How good these are is scored later. That they exist is the gate.
G5: Change policy A written policy on changes to the API Either a promise never to make changes that break existing code, or at least 90 days written notice before one.

A Note on DORA

DORA has applied to EU financial firms since January 2025. It puts the duty on the buyer, not the vendor: it is your firm that cannot sign a contract missing the required terms, and your firm that must list each supplier in a register. For a DORA Article 30 vendor evaluation that means gate G4, and category 8 below for how well the vendor's pack is put together.

TraderMade supports its clients' DORA compliance with a standing third-party ICT risk pack covering service levels, incident notification, business continuity, sub-processors and exit assistance. Our team is available to address any queries regarding our operational resilience measures or the implications of DORA for your organisation. Please reach out to your account representative, or book a call with one of our data experts.


Stage 2: The Scorecard

Ten categories, 100 points, 70 to proceed. Each category has two or three criteria. Score each one from 0 (not answered or fails) to 5 (best in class and provable), and the workbook weights it by the points shown.

The weights below suit a typical trading or treasury team. If you trade at high speed, give latency 20 points or more. If you are a corporate treasury, give resilience and security 15 each. Keep the total at 100 and tell vendors the weights, so they know what you care about. Give each category to the person named as its owner; one person scoring all ten produces a procurement document, not an assessment.

Category Points Who scores it What usually goes wrong
1. Coverage & Sourcing Transparency 10 Head of FX Calculated prices presented as real quotes
2. Data Quality & Timestamp Semantics 12 Quant / data lead Nobody can say what the time label on a price means
3. Cloud Latency & Throughput 15 Platform engineering Data-centre speed figures quoted to a cloud buyer
4. Resilience, SLAs & Failover 12 DevOps / SRE A backup plan that has never been tried
5. APIs, Schemas & AI Readiness 10 Lead architect No machine-readable description, changes without warning
6. Historical Data & Symbology Parity 8 Quant research Old data that does not match the live feed
7. Licensing, IP & Exit Economics 10 Legal / third-party risk Contract silent on sharing the data or training AI on it
8. Information Security & Compliance 8 Security lead Security test missing, or not shared
9. Operational Support & Incident SLA 8 Operations lead Emergencies routed to a generic helpdesk
10. TCO & Commercial Transparency 7 Procurement Cheap headline price that hides extra fees

The 70-point rule. A vendor that fails any Stage 1 gate, or scores below 70 out of 100 on the scorecard, does not qualify for the 48-hour trial.

1. Coverage & Sourcing Transparency (10 points)

The first question everyone asks, and in FX the hardest to answer, because there is no exchange to point at.

  • Real versus calculated prices (4). Some pairs are quoted directly by banks. Others are worked out by the vendor from two other pairs (EUR/CHF from EUR/USD and USD/CHF, for example). Ask which is which. For the big pairs it barely matters. For smaller and exotic pairs it is the whole story. For a worked example of how sourcing differs between feeds, see FX Data Quality Compared: TraderMade vs. Reuters, EBS and Bloomberg.
  • Where the prices come from (3). How many sources feed each pair, what share comes from the biggest one, and what happens to the price if that source goes quiet. Under DORA you are expected to know this.
  • Quiet hours (3). Tick rates and spreads (the gap between buy and sell price) during the Asian session, at the Friday close and at the Sunday open, not just a daily average. If you also need metals, indices or crypto, they should arrive on the same connection, with the same symbol names and under the same contract.

2. Data Quality & Timestamp Semantics (12 points)

A timestamp is the time label on each price. This category carries a high weight because it is where vendors are vaguest.

  • What the timestamp means (4). There are two possible times: when the bank or venue created the price, and when the vendor received or sent it. They can differ by tens of milliseconds. The vendor must say which one you get, how precise it is (seconds, milliseconds), and how it keeps its server clocks accurate (NTP or PTP, the standard clock-sync protocols, with a stated limit on drift). Note: the MiFIR rule on clock accuracy (RTS 25, Commission Delegated Regulation (EU) 2017/574) applies to trading venues and their members, not to data vendors. What you need is a timestamp you can line up against your own records.
  • Catching bad prices (4). Every feed receives occasional nonsense: a price ten times too high, a buy price above the sell price, a quote that stopped updating. Ask what filters catch these (statistical bands, rules for locked and crossed prices) and ask for the method, at least in outline. "Proprietary quality controls" gives you nothing to score.
  • Stale prices (4). The timestamp should be on each price, not one for the whole response, so you can see which pairs moved and which did not. If the vendor serves a cached price because its source went down, that price must still show its old timestamp, and after a set time limit (a TTL, "time to live") the vendor must return an error rather than keep serving it. Otherwise a trading program can act on a price that is minutes old without knowing.

3. Cloud Latency & Throughput (15 points)

The highest weight, and the area most often misrepresented. If your systems run in a cloud region, the only speed that matters is from a client in that region to the vendor's servers.

  • Speed from your cloud region (6). p99 latency over WebSocket (a connection that stays open so prices stream in) measured from a client in the region you name in the RFP. Vendors with servers in several regions, all live at once, score highest.
  • Behaviour under pressure (5). How many updates per second the feed can push before it starts dropping or merging them, the limits on how many pairs and connections you can have, and what happens at those limits during busy moments like US jobs data, inflation data or central bank decisions. Drops should be recorded and reported. Drops that happen silently score low.
  • Reconnecting (4). Every message should carry a sequence number, so when your connection drops and comes back your software can ask for exactly the updates it missed, without being blocked by a rate limit at the worst moment.

4. Resilience, SLAs & Failover (12 points)

An SLA (service level agreement) is the vendor's written promise of what the service will deliver. Most SLAs measure whether a connection exists. This category asks whether the service survives a real failure.

  • Recovery targets (4). Two numbers for the case where the vendor's main region goes down: RTO, how long until the feed is back, and RPO, how much price history is lost. A vendor that keeps a second region ingesting in parallel, so nothing is lost, scores highest.
  • Proof the backup works (4). A test in the last twelve months, with the date and the measured time to recover. A date and a duration, not a target copied from the contract.
  • How uptime is counted (4). Uptime should count whether prices were actually delivered, not just whether the connection was open. Planned maintenance should count against uptime, not be excluded. There should be a public status page with history. And if the vendor breaks the SLA repeatedly within 90 days, you should have the right to leave. The full argument for tick-level measurement, and the contract language that makes it enforceable, is in Beyond 99.9% Uptime: The True Market Data SLA Test.

5. APIs, Schemas & AI Readiness (10 points)

  • One feed, several doors (4). The same prices, with the same symbol names, whether you connect by REST (ask and receive), WebSocket (streaming) or FIX (the messaging standard banks use). Each one sold as a separate product with its own contract scores low.
  • Ready for software clients (3). An OpenAPI file (a machine-readable description of the API), an MCP server or similar so AI tools can connect, with the same access rules as the normal API, and rate limits sized for programs, not for a person refreshing a browser.
  • Getting started (3). From test account to live production in under four hours. If onboarding takes weeks, the integration will be just as heavy.

6. Historical Data & Symbology Parity (8 points)

  • Same shape as live (4). Historical files must use exactly the same field names and symbol names as the live feed. If they do not, your back-tests are testing something different from what you will trade on.
  • Depth and portability (4). At least five years of tick-level history, ready-made data sets for famous stress days (the Swiss franc shock in January 2015, March 2020), and the right to download everything in a standard format when the contract ends.

7. Licensing, IP & Exit Economics (10 points)

This is where the real cost hides.

  • What you are allowed to do with the data (4). Store prices in your own database, show them on internal dashboards, display a conversion rate to your customers, build analytics from them, all without extra per-user fees. Read the licence. If it does not say you can, assume you cannot.
  • AI and model training (3). Explicit permission to train or fine-tune models on the data. Most contracts written before 2023 do not mention it, and silence means no.
  • The cost of leaving (3). Standard formats, no proprietary software library you depend on, and written help with moving out. Then ask the vendor directly what it would cost you to leave. Whether they answer tells you a lot.

8. Information Security & Compliance (8 points)

  • Paperwork for your regulator (3). The vendor's details pre-filled in the format your DORA register needs, a list of the companies the vendor relies on (cloud provider, regions), and notes on any servers outside the EU.
  • Penetration test (3). A penetration test is when a security firm is paid to try to break in. Ask for the vendor's most recent one: what was tested, by whom, when, what was found and what was fixed. Then judge the findings realistically. Every test finds something. What matters is whether anything found affects your use of the service, whether the serious items were fixed and retested, and whether the testers were independent of the people who built the system. A frank list of small, fixed issues is worth more than a clean summary from a tester the vendor will not name. A vendor that will not share its test at all, even under a confidentiality agreement, is a red flag. Certificates like SOC 2 or ISO 27001 add confidence but do not replace seeing the test.
  • Basic hygiene (2). Modern encryption (TLS 1.2 or better), HSTS (a rule that forces browsers to use encrypted connections), no API keys repeated back in error messages or redirects, and connections that have not identified themselves closed within seconds rather than left open.

9. Operational Support & Incident SLA (8 points)

  • Reaching an engineer (4). When the feed breaks in production, a direct 24/7 route to the people who run it. A helpdesk that cannot reach an engineer scores low.
  • Telling you about incidents (2). A written promise of a first report within one to two hours of a serious problem, so an EU client can meet its own four-hour deadline for telling its regulator, and a full explanation within a stated time afterwards.
  • Being open about problems (2). A public status page showing what is working and what went wrong in the past. Vendors who publish their incidents tend to have fewer of them.

10. TCO & Commercial Transparency (7 points)

The lowest weight, because by the time you talk money, price should be the last thing left to decide.

  • The whole cost (4). A three-year total that charges by data volume or connections rather than by number of currency pairs, and includes the engineering work to connect and the cost of moving away later.
  • No surprises (3). Clear limits with gentle slowing down when you reach them, not automatic penalty charges, and annual contracts you can end if the vendor fails to deliver.

The 48-Hour Trial

For vendors at 70 points or above, three tests before anything goes to your lawyers.

  1. The kill test. Cut the connection in the middle of the day. Measure how the feed recovers, whether the sequence numbers let you fill the gap, and how long it all takes.
  2. The stale test. Force or simulate a situation where the vendor's source has stopped. Check that the old prices still show their old timestamps and that, after the time limit, the feed returns an error instead of old prices.
  3. The surprise support ticket. Send a real, technical question at an awkward hour; the Sunday open is ideal. Measure how long the first reply takes and whether it came from an engineer or a script.

Record the results in the PoC Log tab of the scorecard so the trial is scored against the same framework as the written answers. The vendor with the highest combined score is the right vendor. Not the cheapest one. Not the one with the best presentation.


Frequently Asked Questions

What should be included in an FX market data RFP checklist? Five pass/fail gates (written answers, tick-completeness figures, latency as percentiles, the DORA Article 30 contract terms, a written API change policy) followed by a weighted scorecard covering where prices come from, what timestamps mean, speed from the cloud, proof that backups work, readiness for software and AI clients, matching historical data, licence and exit terms, security evidence, support and total cost.

What does DORA require from a market data vendor? DORA puts the duty on the EU financial firm, not the vendor. The firm must have a contract containing the Article 30 terms (what the service is, where data is held, service levels, help during incidents, the right to audit, help on exit) and must list the vendor in its Register of Information. A vendor serving EU financial firms should be able to supply those terms and the register details in writing.

How should latency be measured when choosing an FX data feed? As p50, p95 and p99 percentiles, measured from a client inside the buyer's own cloud region over a stated period. An average, an "up to" figure, or a number measured in a data centre next to the exchange does not describe what a cloud-hosted system will experience.

What is tick completeness in FX, where there is no exchange tape? The share of price updates the vendor accepted into its feed that were actually delivered to the client, per currency pair, over a stated period. Because currencies have no single official tape, completeness can only be measured against what the vendor itself received, so the vendor should also publish how many updates its quality filters rejected and why. A second, simpler check: for major liquid pairs during busy periods there should be no windows where the price goes more than about 15 seconds without an update, or repeats the same quote for that long. A gap like that on EUR/USD in the London session means something upstream is missing.

How many points does a vendor need to reach the trial? 70 out of 100, after passing all five gates. Vendors between 50 and 69 are borderline and need a specific written reason to proceed.


Download the 100-point vendor scorecard matrix (Excel) in the Standard edition or the EU / DORA edition to run the gates, the scorecard and the trial log across up to five vendors. TraderMade's DORA third-party ICT risk pack, including SLA documentation, business continuity plan, Register of Information datasheet and security assessment evidence, is available to enterprise clients on request.

Related Blogs

Talk to a data expert

Choosing a market data provider or planning an integration? Our team can help.

Book a call