An Exchange Gave the Team Seven Days to Add Travel Rule Support. Waiting for an RFP Is Too Late

Signals considered

• The exchange states an integration deadline
• The message names Travel Rule information exchange
• The team starts asking for an API or compliance provider

This is a simulated composite scenario. Its messages, numbers, deadlines and business circumstances are illustrative and do not represent a real customer, conversation, contract or result.

Friday afternoon, and you are a business development lead at a Travel Rule compliance provider, deciding where the rest of your week goes. Your pipeline has a shape: a few active conversations, some quiet leads, and a long tail of industry posts that never turn into anything. One post changes the arithmetic. A compliance officer at a mid-size exchange writes in a Telegram group you are authorized to follow that the exchange has seven days to enable Travel Rule support for a specific asset class, and that vendors wanting to be considered should establish contact before the deadline. No RFP (request for proposal) is attached. No contact name, no asset list, no jurisdiction.

The decision you must make now is whether to spend the next three days working this thread or file it as another policy post. Waiting for an RFP before doing any work feels safe, but with a seven-day window it is the one move that guarantees you arrive late. Acting on every post, though, is how a week disappears without a meeting.

The scene in this article is illustrative. It is not a record of a real exchange, a real group, or a real customer conversation. Every deadline, number and message below is a stand-in for the shape of events you can verify for yourself.

Seven days is a qualification window, not a preparation window

The Travel Rule is the compliance requirement that the originator and beneficiary institutions of a virtual-asset transfer exchange the necessary information about who is sending and who is receiving. It is not one law. It takes different form in different places: FATF Recommendation 16 sets the global baseline, the European Union applies its transfer-of-funds rule, and national regimes in the United States, Singapore and Japan add their own thresholds, asset definitions and enforcement styles. For your business, each regime means a different data set, a different set of counterparties, and a different sales conversation.

A note before the timeline: this article is not legal advice. Whether a given exchange is actually subject to the Travel Rule, for which assets, and in which jurisdictions, is a determination compliance professionals must confirm with the exchange and with counsel. A seven-day post does not change who decides that.

What seven days does change is your internal sequencing. If the exchange issues an RFP next week and you start qualifying then, you will be the vendor writing a response against a deadline instead of the one who already knows the asset scope, the counterparty list and the technical owner.

Day zero: verify the claim, not the channel

On day zero, what you can observe in the message itself: who posted it (a named compliance officer), what they asked for (contact before the deadline), and what they did not include (no RFP, no jurisdiction, no asset list, no technical requirements). What remains unknown: whether this is a formal vendor call, a heads-up to existing partners, or a compliance officer describing an internal deadline out loud. Posting time, display name and the absence of disagreement in the thread are not evidence of seriousness.

Three checks you can run on day zero:

1. Confirm the poster’s identity through the exchange’s public compliance contact page, not through the group profile.
2. Confirm the exchange operates in a jurisdiction where the Travel Rule applies to its activity, and that the named asset class is in scope.
3. Check whether you already have a routing or partnership relationship covering that jurisdiction, because that changes the message you send.

None of these require an RFP. They require an afternoon.

Day two: asset scope and the existing KYC process

By day two the thread usually has replies, and those replies are the evidence. What you can observe: whether the exchange answered follow-up questions about which assets are in scope, which thresholds apply, and which counterparties it expects to exchange data with. What remains unknown: the exchange’s existing KYC (know-your-customer) process, whether it already works with another Travel Rule provider, and whether the seven-day deadline binds the exchange’s own compliance team or third-party vendors like you.

The question that separates a real opportunity from a policy discussion is straightforward: does the thread talk about counterparties and a workflow, or about a principle? “We must comply” is a policy statement. “We need a provider to exchange data with these counterparties by this date” is vendor engagement, even before any RFP exists.

This is also where the tool boundary matters. If a tool like Top Prospect is part of this workflow, it helps in one narrow way: it processes only the Telegram groups you intentionally connect and are authorized to access, keeps the original message, its source and the surrounding context together, deduplicates reposts of the same announcement, and presents a classified list for your human review. It does not automatically contact group members, and it does not certify that any post is a genuine RFP. The call — whether this exchange is worth three days of your week — stays with you, and no tool can make it for you.

Before the deadline: the technical owner and integration conditions

By day four or five, before any RFP exists, you want answers to four questions:

• Who owns the integration on the exchange side — the compliance team, engineering, or a third-party custodian?
• Which data format does the exchange expect — IVMS 101, the standard format for Travel Rule data exchange, or a proprietary schema?
• Which counterparties will the exchange need to exchange data with, and are any of them already your customers?
• What is the real decision deadline — the seven days in the post, or a later procurement cycle?

If your first reply goes out, keep it restrained. A usable version: “Thanks for the notice. We support the jurisdictions your exchange operates in and can confirm coverage and the data formats we exchange before your deadline. Is there a named owner on your side we should coordinate with?” That is one falsifiable question. It promises nothing you have not verified and invents no outcome.

Policy discussion or active vendor engagement?

Signals that point toward vendor engagement: the post names counterparties or a workflow; the poster answers scoping questions; an owner is named on the exchange side; the deadline is tied to a concrete milestone such as a regulatory examination or a licensing condition. Unknowns that should keep you honest: no jurisdiction named, no asset list, no owner, and a thread that stays at the level of principle. None of those unknowns prove the opportunity is fake; they only mean the evidence is incomplete. A seven-day clock is not urgency by itself.

The deadline belongs to the exchange; the first two days belong to you

The post’s deadline is the exchange’s internal constraint, and it may move. What you control is the first two days: identity check, jurisdiction check, relationship check, then asset scope and the existing KYC process, then the technical owner and the data format. If the RFP arrives, you arrive with verified answers. If it never arrives, you spent two days instead of seven, and the thread stays what it always was — one message in an authorized group, waiting on a human decision. That is the decision the RFP, when it comes, will reward.