Notabene Integration

Today, we’re announcing native support for the Travel Rule within the Dfns wallet infrastructure, through a direct integration with Notabene. This allows our customers like exchanges, fintechs, custodians, and other Virtual Asset Service Providers (VASPs) to meet growing global compliance obligations, without the overhead of building or managing a standalone Travel Rule stack. Instead of treating compliance as a separate layer, Dfns treats it as part of the wallet infrastructure.

What is the Travel Rule, and why does it matter?

The Travel Rule was introduced by the Financial Action Task Force (FATF) and has since been adopted globally in various forms. It requires Virtual Asset Service Providers (VASPs) to exchange identity information about the originator and beneficiary of a crypto transfer before the transaction is executed. In effect, it brings crypto in line with how financial institutions use SWIFT to share metadata for fiat wire transfers. Key jurisdictions have implemented or are in the process of implementing the rule:

• European Union: Under the Transfer of Funds Regulation (TFR), every crypto transaction, regardless of amount, must comply, including transfers between self-hosted wallets and VASPs.
• United States: The $3,000 threshold still applies under FinCEN regulations, but enforcement has tightened.
• Singapore, Switzerland, Japan, UK: These jurisdictions have adopted FATF-aligned Travel Rule frameworks, with increasing supervisory scrutiny.

For VASPs, non-compliance means real consequences: fines, license suspensions, audit failures, and even the risk of losing access to banking and payment networks. The complexity lies in navigating varying thresholds, coordinating with counterparties, exchanging encrypted messages, and deciding what to do when something fails.

How the Dfns/Notabene integration works

With our new Notabene integration, Dfns abstracts this entire process. Instead of building Travel Rule support internally, or bolting it on awkwardly, compliance becomes a first-class part of the Dfns transaction management service. Travel Rule compliance typically requires VASPs to exchange personally identifiable information (PII) or cryptographic proofs before a transfer is confirmed. This data includes:

• Originator info (who's sending the funds)
• Beneficiary info (who's receiving the funds)
• Either a VASP identifier (DID) for custodial transfers or a compliance proof for self-custody wallets

The encrypted payload is routed to Notabene, which acts as a neutral message coordinator between VASPs. Based on the result, whether the message was confirmed, rejected, or flagged as incomplete, Dfns enforces your organization’s compliance policies through our policy service. You remain in control of what happens next: whether to allow, block, or escalate the transaction before it's broadcasted onchain.

When initiating a transfer, you can now include an optional travelRule object in the request body. This field is designed to carry all required metadata: originator information, beneficiary details, and either a counterparty VASP identifier (DID) or a proof for non-custodial transfers. Example:

{
  "type": "Notabene",
  "beneficiaryVaspDid": "did:example:123",
  "beneficiaryProof": {
    "type": "cryptographicProof",
    "data": "encrypted-payload"
  },
  "originator": {
    "accountNumber": ["encrypted-string"],
    "originatorPersons": [
      { "naturalPerson": { /* optional fields */ } },
      { "legalPerson": { /* optional fields */ } }
    ]
  },
  "beneficiary": {
    "accountNumber": ["encrypted-string"],
    "beneficiaryPersons": [
      { "naturalPerson": { /* optional fields */ } },
      { "legalPerson": { /* optional fields */ } }
    ]
  }
}

All PII is:

• Encrypted client-side using Notabene’s SDK
• Never decrypted by Dfns
• Validated by Notabene’s API which tells us if the payload is sufficient

A closer look at the technical design

The travelRule object is structured to support both custodial and non-custodial flows. For example, you might pass a beneficiary VASP DID for an institutional counterparty, or include a cryptographic proof for a self-custody wallet. The schema is flexible, composable, vendor-agnostic, and built to support Notabene now as well as others in the future.

We chose not to break this into rigid sub-cases. Instead, we use a clean discriminated union to support extensibility across vendors, while validating the structure of the data using Zod. If something’s missing or invalid, Notabene will tell us, and our policy service will handle the failure in accordance with your rules. Dfns acts as the orchestrator, not the validator.

There’s no need to re-enter metadata like asset type or amount as those fields are already part of the original transfer body. Nor do you need to manage webhook delivery yourself. Dfns generates and hosts the webhook URL, while the customer registers it in Notabene’s dashboard. All updates (i.e., delivery status, validation results, exception flags) flow directly into our policy service for automated handling.

Workflow summary

1. Client adds a travelRule object to the transfer request.
2. Dfns forwards encrypted payload to Notabene.
3. Notabene validates the message, matches counterparties, and returns a result.
4. Dfns enforces policy: allow, block, or flag, all automatically.
5. Webhook-driven architecture lets you audit and react in real time.

Policy behavior is customizable:

• Block on timeout or incomplete data
• Trigger escalation flows
• Adjust enforcement by jurisdiction, counterparty type, or amount
• Auto Resolve if Message is Delivered to a counterparty that does not respond within a certain timeframe

Key takeaways for fintechs getting into digital assets

Implementing Travel Rule compliance typically requires product teams to build message formatting logic, secure encrypted payload delivery, route exceptions, manage retries, and host dashboards for auditing. It’s an expensive and sensitive engineering task that distracts from core business goals.

With Dfns and Notabene, compliance becomes something you configure, not build. You define your policy; Dfns enforces it. The infrastructure does the heavy lifting. PII never touches our systems, transaction logic remains clean, and compliance becomes a programmable layer. Not a manual one. This is especially useful for regulated institutions like custodians, exchanges, and fintech platforms that deal with cross-border transfers and must adapt to different jurisdictional requirements. Now, a single integration covers the EU, US, and other FATF-aligned regimes with minimal operational overhead.

Whether you’re:

• A fintech wiring stablecoins
• A custodian moving client crypto funds
• An exchange processing withdrawals

You now get a plug-and-play compliance layer, without:

• Disclosing PII
• Building message logic
• Maintaining vendor SDKs

Start enforcing Travel Rule compliance using the Dfns wallet infrastructure today, securely and at scale: https://app.dfns.io/get-started 

‍