Travel Rule — Post 1 July 2026

⚠️

Enforced from 1 July 2026

From this date, Travel Rule is enforceable across the BEEM Portal and API. Channels, Payment Links In, and Payment Links Out must carry a linked Contact (in the Portal) or a populated complianceDetails object (on the API). Payments without the required information are blocked at create time, or held against an RFI until a Contact is assigned.

What's changing now

BEEM now enforces the data model put in place during the Pre period:

In the Portal

Creating a Channel

The Channel creation form now requires a linked Contact. Pick from the saved Contact list or create a new Contact in line. The Contact stays associated with the Channel for Travel Rule purposes.

Payment Link In / Receive Crypto

Creating an inbound Payment Link now requires you to select the Contact representing the customer who will pay (the originator). If you haven't saved the customer as a Contact yet, create one first.

Send Crypto / Payment Link Out

Creating an outbound payment requires you to select the Contact representing the recipient (the beneficiary). The Send Crypto and Payment Link Out flows both enforce this.

Missing Contact page

A new top-level Missing Contact page in the Portal sidebar surfaces every payment waiting on Contact assignment. Typical entries:

• A Channel deposit arrived from a sender BEEM doesn't have Contact details for — link a Contact representing the originator.
• A payment created with partial complianceDetails needs additional verification — update or replace the linked Contact.

From the Missing Contact page:

1. Open the pending item.
2. Select an existing Contact, or create a new one in line.
3. Submit. The payment proceeds and the item leaves the queue.

The Missing Contact page is the operations equivalent of the API's Travel Rule RFI flow — both surface the same set of payments awaiting resolution.

Via the API

complianceDetails is required

On Create Channel and Create Payment Link requests, complianceDetails is now mandatory:

• POST /api/v2/channel — CreateChannelRequest.complianceDetails
• POST /api/v1/pay/summary — PayRequestDto.complianceDetails

Two ways to populate it. Either is acceptable.

Option 1 — contactId (recommended)

{
  "complianceDetails": {
    "contactId": "1b083898-73ca-42ba-b433-7dc20ea67667"
  }
}

Option 2 — partyDetails[] inline

{
  "complianceDetails": {
    "partyDetails": [
      {
        "type": "BENEFICIARY",
        "entityType": "COMPANY",
        "legalName": "Acme Corp",
        "registrationNumber": "12345678",
        "relationshipType": "THIRD_PARTY",
        "address": {
          "addressLine1": "1 High Street",
          "city": "London",
          "country": "GB",
          "postCode": "EC1A 1BB"
        }
      }
    ]
  }
}

If complianceDetails is missing — or doesn't meet the requirements — the request returns 400 Bad Request with a description of what's missing. Fix and resend.

Handling Travel Rule RFIs

Even with complianceDetails provided at create time, BEEM may raise a Travel Rule RFI (Request for Information) against a payment when extra information is needed — for example, a channel deposit from a sender you haven't yet linked to a Contact. Until the RFI is resolved, the payment is held against the RFI.

BEEM does not emit a dedicated "RFI raised" event. Detection runs through the existing transaction-held webhooks; resolution runs through the Travel Rule RFI endpoints.

Step 1 — Detect via transaction-held webhooks

The signal that an RFI may exist is the standard hold event firing on the affected payment:

The payload structure is unchanged from its existing meaning — there is no Travel Rule flag on the event itself.

📘

These events are shared with KYT

A transaction-held delivery may indicate either an open Travel Rule RFI or a KYT (Chainalysis) screening flag. The payload does not say which. You must use Step 2 to determine the hold reason before reacting.

Step 2 — Confirm by listing RFIs

On every transaction-held delivery, call:

GET /platform/v1/travel-rule-rfis

If an open RFI exists for the held payment, the hold is a Travel Rule matter — proceed to Step 3. If no RFI is returned, the hold is being driven by KYT or another compliance process — route it to your existing remediation workflow and do not call assign-contact.

Step 3 — Resolve via assign-contact

PATCH /platform/v1/travel-rule-rfis/{externalId}/assign-contact

Submit contact details to satisfy the RFI. The endpoint accepts three request body shapes — pick whichever matches your situation:

• An existing contactId (from your Contacts store) — recommended.
• Inline Individual details — for natural-person counterparties, creates the Contact in the same call.
• Inline Company details — for legal-entity counterparties, creates the Contact in the same call.

BEEM validates the data against the requirement and resolves the RFI. The held payment proceeds.

See Building a Travel Rule Integration for the three request body shapes in detail and the recommended cross-API system design.

Webhooks

There is no dedicated "RFI raised" webhook event. Subscribe to the existing transaction-held events — layer1:payment:channel:transaction-held and layer1:payment:checkout:transaction-held — via your Hook configuration. These events also fire for KYT screening holds, so your handler must call GET /platform/v1/travel-rule-rfis on every delivery to determine whether the hold is a Travel Rule matter. See Events for the event payload shapes.

📘

Held payments are recoverable

A payment held against an RFI is not lost. The funds stay safe until you assign a Contact — at which point processing resumes from where it paused. Treat RFI resolution as routine ops, not as a failed payment.

How to be ready

1. Confirm every Create Channel and Create Payment Link call now includes complianceDetails. Catch any code path that doesn't before 1 July.
2. Subscribe to the transaction-held webhooks (layer1:payment:channel:transaction-held and layer1:payment:checkout:transaction-held) so your system reacts in real time rather than polling. On every delivery, call GET /platform/v1/travel-rule-rfis to determine whether the hold is a Travel Rule RFI or a KYT flag.
3. Train your operations team on the Missing Contact page. This is the human fallback when programmatic resolution isn't possible.
4. Use the Contacts-first pattern wherever you can — repeat counterparties saved once, reused on every payment, edited in one place.
5. Read Building a Travel Rule Integration for the recommended cross-API system design.

What's next