We refreshed our doc site!
Bookmarked links may have changed
Read release notesThe Verite open source repo includes some code that provides a cursory demonstration of how exchanging verifiable credentials could be a core component of scalable and open ecosystems for financial institutions to comply with Travel Rule reporting obligations with minimal privacy, data leakage, and security risks.
In addition to this high-level "proof of concept," long-tail research in ongoing into FATF use cases forming a cornerstone of Verite in the latter part of 2023.
Please note: TRUST, TRISA, and other protocols that currently do not use Verifiable Credentials as an exchange format for FATF counterparty reporting are in no way incompatible with this group's approach; our goal is to focus on the privacy risks and protocols for mutual discovery and interactions, which can bootstrap any protocol between financial institutions once validated.
The "Travel Rule" refers to the U.S. Bank Secrecy Act rule as well as guidance defined by the international Financial Action Task Force (FATF) Recommendation 16. The Travel Rule requires Financial Institutions (FIs) and what FATF refers to as Virtual Asset Service Providers (VASPs) to exchange and analyze specific PII data about the originator and beneficiary of a given transaction when such a transaction exceeds a threshold of notional value (the threshold is 3000 USD value for the US BSA version and 1000 USD/EUR value for FATF version). The purpose of these regulations is to police financial crime such as money laundering, block terrorist financing, stop payments to sanctioned entities and countries by requiring intermediaries to report threshold-exceeding transaction and combine those reports with other monitoring to detect and investigate suspicious activities. Since most prosecution and tort discovery of these crimes leans heavily on forensics, this reporting is often archival in nature and format.
Mapping Travel Rule requirements to blockchain transactions poses several challenges. One such problem is "discoverablility" -- knowing when a beneficiary/recipient address is managed by a financial institution and therefore when Travel Rule obligations exist, and furthermore how to contact the recipient institution to execute secure counterparty data exchange. At broadcast time, the originator of a blockchain transaction has no means of knowing whether a recipient address is custodied by a financial institution or VASP, much less which one, and furthermore no means of directly contacting the owner or custodian of that address.
The crypto ecosystem has proposed many potential solutions to this problem over time:
Many of these approaches are either greenfield approaches requiring vast, new platforms to be established quickly, or empower dangerously omniscient data barons to be the only possible middlemen regulators and end-users alike can trust to enforce reporting and monitoring. The governance of those platforms and/or middlemen poses, for us, a real challenge to the "opt-in", pseudonymous-by-default ethos of web3, but proposing a cogent, researched, prototyped alternative is worth a thousand eloquent critiques so we have been working on the former rather than stacking up the latter.
Our design goal in our research and design has been to focus on the privacy problems of discoverability and trust establishment between VASPs and FIs (and perhaps even self-custodied wallets!), imagining an open platform that does not compromise the anonymity guarantees of today's blockchains and marketplaces.
The Verite research group has sketched out a "Verite-maximalist," privacy-preserving architecture for solving these problems by:
Note: The "travel rule" demo in the Verite codebase on github demonstrates one implementation of 1, which we call the "mempool" implementation of a "bulletin board" messaging-based discovery architecture; 2 is still in research phase; and 3 can be achieved today by protocols like TRUST or TRISA, albeit not yet in verifiable credential form.
Note, the following diagram reflects the prototype on github, which predates much of the exploratory/theoretical design work of the FATF working group within Verite's open-source development initiative. The text below presents an expanded, more detailed view; for an understanding of the prototype, refer to the diagram wherever the two differ.
Crucial to the design of our system is some kind of bulletin board system which can be conceived of as a miniature "mempool", i.e. a smart contract that hosts ephemeral messages posted publically for the express purpose of being responded to privately by self-authenticating parties.
Before an intended/proposed transaction is broadcast, the sending and receiving FIs use this chain-agnostic "bulletin board" to publish and observe messages establishing and requesting proof of address control. These messages contain no customer data and no specific transaction data other than the recipient address (hashed) and the identity of the sender's custodian.
Since the transaction amount is not included, observers are unable to determine information about the planned transaction other than its intended origin and destination (this is less information than is available in the EVM-wide mempool, for example, which broadcasts entire transaction ready to be added to blocks). This allows counterparty endpoints to find and connect to one another privately before exchanging counterparty information, and the mutual exchange of proof-of-control credentials for both addresses prevent any other party from spoofing the originator or beneficiary.
The trust establishment step (which some might think of as an "anti-spam"/"anti-DoS" step to avoid spam or data-collecting crawlers) is not included in the simplified prototype in our repo. There are various prototyping efforts happening in the DIF and elsewhere that may prove adequate for this step, so we are deferring research on it in case open-source specifications get hardened in the meantime for this kind of authentication and public trust registry building.
service
type. One simple DID method for this would be did:web
, conducive to manual/human-readable fall-backs and auditability without reliance on blockchains or other novel architectures.If Alice's FI determines the transaction does not meet the threshold required for the Travel Rule after establishing both Alice's and Bob's requirements by jurisdiction, then Part 3 is not necessary and does not apply, as Alice's FI can simply proceed to broadcasting the blockchain transaction.
If the Travel Rule does apply, however, both financial institutions are able to exchange counterparty verifiable credentials over callback URLs that allow for private secure communication. This can happen over any secure channel, and today is mostly done in consortium/network-like platforms that bundle the authentication of step 2 and the secure channel for step 3 (as well as data dictionaries or translation enginges for exchanging the actual information required by applicable reporting requirements, itself a massively complex value-add and rules engine). This research could be called long-tail, as the rapid pace of regulatory change here means the existing protocols will probably be distracted updating their rules engines for some time and not have bandwidth to consider harmonizing on UX and consent flows!
As a prototype of user-centric UX and an architecture that layers consent receipts on top of reporting artefacts, the Verite prototype models how identity-enabled and verifiable-credential-enabled wallets could surface meaningful and direct consent into such a flow. While traditional financial institutions typically require their users to consent to terms and conditions that grant the rights to transfer this kind of private information, this prototype of more proactive and per-interaction consent could pave the way to better support for non-custodial wallet compliance, or conformance to more aggressive regulation about meaningful consent. To address this latter hypothetical requirement, the flow presents notifications as alerts to customers so that they have visibility into when their data is requested, and to provide them the choice to cancel sending or receiving transactions that require such counterparty credentials exchange.
Note that this sequence is intended only as a demonstration of how exchanging verifiable credentials may be helpful with Travel Rule requirements. We lean heavily on the expertise of companies already working in this space and protocols already in place to exchange counterparty information securely between Financial Institutions.
Production-level topics such as spam prevention in the bulletin board, cross-chain and multi-swap messaging complications, smart-contract-based wallets and other multisignature counterparties, and private key security protections are beyond the current scope and are among several subjects to address in future development and exploration.