Know the institution before the data travels.

Most of what gets written about the Travel Rule is about the customer. Which fields describe the person sending the funds, which describe the person receiving them, how to format them, and which messaging protocol carries them. That is the visible part of the rule, and it is where most engineering effort goes.

The less visible part is the other institution. The Travel Rule is a rule about sending identifying information about your customer to someone else. Before any of that information leaves, somebody has to decide who the receiving institution is, whether it is the institution it says it is, and whether it is one you are willing to send a customer’s name, address and account number to. That decision rests on documents, and the documents belong to the counterparty, not to the customer.

This piece is about those documents: what a counterparty review packet usually contains, what each document can and cannot establish, how the documents should be checked against each other, and when the evidence stops being current. It is written from the United States rules, because those are the ones quoted here from primary text. It is not legal advice, and it does not describe any other jurisdiction’s requirements.

What the rule makes you send, and to whom

In the United States, the Funds Travel Rule is 31 CFR 1010.410(f). It applies to a transmittor’s financial institution or an intermediary financial institution located within the United States, for a transmittal of funds of $3,000 or more. Under paragraph (f)(1), the transmittor’s institution includes in the transmittal order, at the time it is sent to the receiving institution, the transmittor’s name and, if the payment is ordered from an account, the account number; the transmittor’s address; the amount; the execution date; the identity of the recipient’s financial institution; as many of the recipient’s name and address, account number and other specific identifier as were received; and either the name and address or a numerical identifier of the transmittor’s own institution. Paragraph (f)(2) requires an intermediary to pass the same information along, as received.

FinCEN applied this to convertible virtual currency in its guidance FIN-2019-G001, issued May 9, 2019. The guidance says that a transmittal order involving convertible virtual currency is an instruction to pay a determinable amount of money, so such transactions qualify as transmittals of funds and may fall within the Funds Travel Rule. It says the threshold is $3,000 or more, or its equivalent in virtual currency. And it says the money transmitter must obtain or provide the required information either before or at the time of the transmittal of value, while allowing that information to travel in a message separate from the one that moves the value. The guidance states that it does not establish new regulatory expectations; it explains how existing rules apply.

Two details in that text matter for counterparty review more than they first appear to.

• The recipient’s institution is a field you fill — paragraph (f)(1)(v) asks for the identity of the recipient’s financial institution. In a bank wire, that identity is usually printed in the payment instruction. In a virtual currency transfer, what the sender sees first is often an address or a protocol identifier, and turning it into a named institution is a step someone has to take.
• The identity has to be decodable — FIN-2019-G001 repeats earlier FinCEN guidance that an originating or intermediary institution which replaces the proper identity of a transmittor or recipient with a pseudonym or reference the receiving institution cannot decode is not complying with the Funds Travel Rule. The same logic runs in the other direction for your own records: a counterparty known to your system only by an identifier, with no legal entity behind it, is not a counterparty you have identified.

The rule text quoted above does not prescribe a counterparty review procedure. What it does is require you to name the receiving institution and to send it personal information about your customer. The review is how you know both of those acts are aimed at the right party.

A counterparty is a packet of documents

When one virtual asset business evaluates another, the evidence arrives the way most compliance evidence arrives: as a bundle of PDFs, scans and filled-in forms, sent by email or uploaded to a portal, in whatever order the other side assembled them. The contents vary by institution and by the reviewer’s own policy, but most packets draw on the same handful of document types.

The right-hand column is the important one. Every document in the packet is a partial claim made by the counterparty, or by an authority about the counterparty, at a particular date. None of them alone answers the question a reviewer is actually asking. The answer comes from reading them together.

The registration record is a declaration with a date on it

For a money services business in the United States, the federal registration is the document most reviewers reach for first, and the rule that governs it explains what it is. Under 31 CFR 1022.380(a)(1), each money services business, whether or not it is licensed by any state, must register with FinCEN. FIN-2019-G001 states that persons accepting and transmitting convertible virtual currency are money transmitters, and that the registration and other obligations apply equally to foreign-located money transmitters doing business in whole or in substantial part within the United States, even without a physical presence there.

The rest of the section is what makes the registration record useful as evidence, and also what limits it.

• It is filed by the business — registration is made by filing a form, and section 1022.380(e) treats the filing of false or materially incomplete information as a failure to comply. The record is a statement the business made about itself. It is not an assessment of the business by anyone else.
• It runs in two-year periods — under section 1022.380(b)(2), the initial registration period is the two-calendar-year period beginning with the calendar year in which the business is first required to register, and each two-calendar-year period after that is a renewal period. Under (b)(3), the renewal form is due on or before the last day of the calendar year preceding the renewal period.
• Some events restart the clock — under section 1022.380(b)(4), a business must re-register within 180 days after a change in ownership or control that requires re-registration under state law, a transfer of more than 10 percent of its voting power or equity interests, or a more than 50 percent increase in its number of agents during a registration period.
• A foreign-located business names someone in the United States — under section 1022.380(a)(2), a foreign-located money services business designates a person residing in the United States as its agent to accept service of legal process, and identifies a US location for its records.

Read as an extraction specification, that list says the registration record needs more than a number. It needs the legal name exactly as filed, the registration period it covers, the date it was filed, and, for a foreign-located counterparty, the US agent and address. Those are the fields that the rest of the packet is checked against, and the fields that tell you when the record has to be looked at again.

It also says the record should be confirmed, not just read. FinCEN publishes a searchable list of registered money services businesses. A reviewer who checks the extracted registration number, legal name and filing date against that source has evidence of a different kind from one who copied the same values off a PDF the counterparty sent. The pipeline should record which of the two it has.

The checks are between documents

Extracting each document well is the easy part. The value of a counterparty packet is in the places where its documents should agree and do not. A small set of cross-checks catches most of what a reviewer would otherwise find by reading everything twice.

• One legal name — the registration, the licences, the formation certificate, the questionnaire and the technical attestation should name the same legal entity. A trade name on the questionnaire is fine if the registration lists it. A different legal entity, such as an affiliate or a parent, is a finding: it means the packet describes more than one institution, and only one of them will appear as the recipient’s institution in your records.
• Ownership that matches its own triggers — if the ownership chart shows a change of more than 10 percent since the date of the registration record, the registration rule says a re-registration was due within 180 days. A chart dated after that window, paired with a registration filed before the change, is a question to ask the counterparty, not a conclusion to draw.
• Dates that are current on the review date — every document carries an as-of date: a registration period, a licence expiry, a certificate date, a questionnaire signature, a programme approval. The pipeline should compute, for each one, whether it is current on the day of the review, and keep that computation with the evidence.
• Answers that agree with attachments — a questionnaire that says the programme was approved this year, attached to a programme summary dated two years earlier, has a contradiction in it. So does a questionnaire that lists licensing in three states next to a licence list that shows two.
• Identifiers tied to the entity — the technical attestation lists the identifiers your systems will actually see during a transfer. The link between those identifiers and the legal name in the registration is the link that lets your Travel Rule message name the right institution. If the attestation is unsigned, undated or issued by a different entity, that link is unproven.
• A signatory who can sign — the questionnaire and the attestation should be signed by someone the other documents identify, such as the named compliance officer or a listed controller, on a date that falls inside the period the answers describe.

None of these checks requires judgement about whether the counterparty is acceptable. They establish whether the packet describes one institution consistently, at a known date. That is the precondition for anyone to make the judgement well.

A packet ages, and the age is extractable

A counterparty review is not finished when the reviewer signs it off. The registration rule itself describes the ways a record goes stale: the period ends, a renewal is due, ownership changes, the agent network grows. Licences expire on printed dates. Questionnaires describe a programme as of a signature date. A review that stores only the decision, and not the dates the decision rested on, has no way to know when it should be done again.

So the output of the review should carry a schedule, derived from the documents rather than set by a fixed calendar.

• The earliest expiry — the soonest date on which any document in the packet stops being current, computed from licence expiries and the end of the registration period.
• The renewal checkpoint — for a federal registration, the last day of the calendar year before the next renewal period, which is when a renewed record should exist.
• The event triggers — a change of ownership or control, a new legal name, or a new identifier in the technical attestation, any of which should reopen the review rather than wait for the next date.
• The oldest attestation — the questionnaire or attestation with the earliest signature date, because it is the part of the packet most likely to describe a programme that has since changed.

How often a counterparty must be reviewed is a policy decision, and the policy belongs to the institution doing the review. What a document pipeline can do is make sure that policy is applied to the dates actually printed in the packet, not to the date someone remembers uploading it.

What the extraction should deliver

For each counterparty packet, a pipeline built for this review produces a record alongside the usual extracted fields:

• The document classes — registration, licence, formation, ownership, programme summary, questionnaire, attestation, each with the confidence of the classification and the documents the packet is missing.
• The entity — one legal name, its trade names, its registration and entity numbers, its jurisdiction, and every place in the packet where a different entity appears.
• The dates — each document’s as-of date, expiry or period end, and whether it is current on the review date.
• The contradictions — each pair of documents that disagree, with the field, both values and the source region on each page.
• The source of each fact — whether a value was read from the counterparty’s document or confirmed against a public registry, and when.
• The schedule — the earliest expiry, the renewal checkpoint and the events that should reopen the review.

The decision stays with the compliance team. A pipeline can show that a registration period ends at the close of the year, that the ownership chart contradicts the registration date, or that the technical attestation names an affiliate. Whether to accept the counterparty, ask for more, limit transfers or decline is a judgement under the institution’s own programme, and an extraction system that makes it on its own has taken a decision it cannot defend.

Not customer onboarding, not vendor review

Three neighbouring problems use some of the same documents and are easy to blur into this one.

Customer identity checks look at the person or business on whose behalf funds move. The proof-of-address article covers one part of that, and the tax residency article covers the self-certifications a customer signs. The counterparty in this piece is not a customer. It is another obligated institution, with its own customers and its own programme.

Vendor due diligence looks at a supplier you contract with, such as a model provider, and the risks of depending on it. The frontier provider article discusses that review. A Travel Rule counterparty is not your supplier. You may have no contract with it at all; you are sending it data because a transfer and a regulation require you to.

Sub-processor review looks at the parties that process personal data on your behalf under a data processing agreement, which the sub-processor article describes. A receiving institution is not processing your customer’s data on your instructions. It receives the data for its own obligations, which is exactly why knowing who it is matters before the data leaves.

The data travels to someone

The Travel Rule is usually discussed as a formatting problem: which fields, in which message, by which protocol. The fields are only half of the transfer. The other half is the institution named in paragraph (f)(1)(v), and the confidence that it is a real, consistently described, currently registered institution rests on a packet of documents that were each true on some date. Reading those documents as a set, checking them against each other and against public sources, and keeping their dates is what turns a counterparty name in a message into a counterparty you actually know.