Travel Rule — Pre 1 July 2026

🚧

Optional during this period

Up to and including 30 June 2026, all Travel Rule requirements on BEEM are optional. Payments process whether or not Travel Rule details are supplied. Use this window to populate Contacts and exercise the complianceDetails API so your integration is ready for enforcement on 1 July 2026.

What's changing now

BEEM is putting the data model and API in place that will be enforcable from 1 July 2026. During this period:

In the Portal

Contacts

The Contact form already collects the data BEEM needs for Travel Rule purposes through its existing required fields. The required set differs by Contact type:

Address, post/zip code, region/state, date of incorporation and the "This is my company" toggle remain optional. See Contacts for the full form and walkthrough.

Populating Contacts now ensures every counterparty you transact with has a Travel-Rule-ready record before enforcement begins.

Send Crypto / Payment Link Out

When creating an outbound payment from the Wallets page or via Payment Links Out, you can link a saved Contact. The Contact's stored details are associated with the payment. Linking a Contact is optional pre-1 July.

Payment Link In, Channels

No Travel Rule UI surface during this period. No change to how you create channels or receive Payment Link In deposits in the Portal.

Via the API

The API already exposes the full Travel Rule data model — but everything in it is optional.

complianceDetails on Create requests

Both Channels and Payment Links accept an optional complianceDetails object on their create endpoints:

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

There are two ways to populate it. Both satisfy the Travel Rule data requirement; both are optional during this period.

Option 1 — link a Contact (recommended)

Pass complianceDetails.contactId referencing a saved Contact. BEEM pulls the regulated counterparty data from the Contact, so your Contacts store remains the single source of truth.

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

Option 2 — inline party details

Pass complianceDetails.partyDetails[] with each party's information inline. Each entry is either an Individual or a Company (discriminator entityType) and tagged as a BENEFICIARY or ORIGINATOR.

{
  "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"
        }
      }
    ]
  }
}

Use contactId or partyDetails[] — the contactId path is recommended for repeat counterparties because data lives in one place and updates flow through to every subsequent payment automatically.

What happens if you omit complianceDetails?

The request processes as it always has. No payment is held, no error is returned. From 1 July 2026 the same request without complianceDetails will be rejected — start including it now so your integration is ready.

Inbound payments via the API

No new rejection rules apply to inbound flows pre-1 July. Create requests on Payment Link In and channel reads are unchanged from the existing behaviour.

📘

No payment impact during this period

Pre-1 July, payments without complianceDetails (or without a linked Contact on outbound) still create, accept, and settle as before. From 1 July 2026 the same payment will not be able to proceed without it.

How to use this period

1. Audit your Contacts. Every counterparty you transact with regularly should be a saved Contact with the required fields completed correctly.
2. Adopt complianceDetails in sandbox. Start passing the object on Create Channel and Create Payment Link requests so your integration code paths already exist before enforcement.
3. Pick your adoption path. Decide whether you'll use contactId (Contacts as the source of truth) or partyDetails[] (inline data). For most merchants, the Contacts path is the cleaner long-term choice.
4. Plan for inbound coverage. From 1 July 2026, Travel Rule will extend to Payment Link In and channel creation in the Portal too — start designing how you'll associate Contacts for those flows.
5. Watch the Changelog for production availability and pre-enforcement updates.

What's next