Skip to main content
DFNS helps you comply with the FATF’s Travel Rule through its integration with Sumsub. Outgoing transfers carry the originator and beneficiary information in the IVMS101 format, encrypted on your side with your Sumsub integration’s public key. DFNS never decrypts this data.

​
How to set it up

Before Sumsub Travel Rule policies can be defined, you must:
  • Have a Sumsub account with Travel Rule enabled
  • Have Travel Rule enabled for your DFNS tenant and the Sumsub integration activated on your organization. Reach out to your DFNS representative to activate it.

​
Organization settings

The integration is configured on your organization with your Sumsub credentials: the app token, the secret key, and the webhook secret. DFNS stores all three encrypted at rest. All three are required: without them, Sumsub travel rule evaluations fail and the policy triggers.

​
Sumsub webhook

DFNS learns the final status of a Travel Rule message (TRM) from Sumsub webhooks. In Sumsub, point the webhook to:
Replace {orgId} with your organization ID, and use the API base URL of your region. DFNS verifies each push against the X-Payload-Digest header, an HMAC of the raw body keyed with your webhook secret. The algorithm is read from X-Payload-Digest-Alg: HMAC_SHA256_HEX, HMAC_SHA512_HEX, or HMAC_SHA1_HEX. A push without X-Payload-Digest-Alg is verified as HMAC_SHA1_HEX, which older Sumsub webhooks use. A push with an invalid signature is rejected with 401.

​
Policy

Outgoing transfers are screened for Sumsub Travel Rule compliance by a policy with the following traits:
Unlike the Notabene configuration, the Sumsub configuration has no autoClearAfterDeliveredTimeoutSeconds setting. The rule only applies to transfers initiated through the Transfer Asset API. It is not supported for transfers initiated from the dashboard. A transfer sent without a travelRule payload does not trigger the rule.
The travel-rule vendor is determined by the policy rule’s configuration.vendor, and the transfer’s travelRule payload must be of the matching kind. A mismatch triggers the policy and applies its configured action. A given wallet must be covered by at most one travel-rule policy, of any vendor. If several travel-rule policies apply to the same transfer, DFNS treats it as a misconfiguration and blocks the transfer without contacting any vendor.

​
Screening flow

When the policy evaluates a transfer, DFNS creates a TRM at Sumsub and acts on the status Sumsub returns: The policy also triggers without creating a TRM when the asset is not supported, or when the transfer’s source address or asset decimals are unknown. If the call to Sumsub fails, the policy triggers. After the evaluation, DFNS keeps the TRM in sync with the transfer:
  • When the transfer confirms on chain, DFNS finalizes the TRM with the transaction hash.
  • When the transfer is blocked, rejected, fails, or is cancelled, DFNS cancels the TRM.

​
Supported assets

The Sumsub integration supports these assets. Any other asset or token contract triggers the policy.

​
Encrypt the IVMS101 payload

The originator and beneficiary information must follow the IVMS101 (interVASP Messaging Standard 101) format, version IVMS101.2023, and is encrypted client-side before it is sent with the transfer.
1

Retrieve the Sumsub public key

Call Get Sumsub Travel Rule public key. It returns the RSA public key of your organization’s Sumsub integration as a JWK (RFC 7517). The call fails with 412 if Travel Rule is not enabled for your tenant or the Sumsub integration is not activated on your organization.
2

Build the IVMS101 payload

Fill in the originator and beneficiary information using the IVMS 101.2023 field names (for example Originator.originatorPerson[], Beneficiary.beneficiaryPerson[], naturalPersonNameIdentifierType), and set payloadMetadata.payloadVersion to 101.2023. Without it, Sumsub parses the payload as IVMS 101.2020 and ignores the 2023 field names. Keep the list of IVMS101 field paths you filled in (for example Originator.originatorPerson[].naturalPerson.name.nameIdentifier[].primaryIdentifier and payloadMetadata.payloadVersion). You send this list as filledFields.
3

Sign, then encrypt

Sign the payload as a JWS, then encrypt the result as a JWE with the Sumsub public key, using RSA-OAEP-256 for key encryption and A256GCM for content encryption. Use the compact serialization. The result is the data value.

​
Travel Rule transfer payload

Once the integration is configured and a policy is in place, send transfers with a travelRule field of kind Sumsub. Set exactly one of beneficiaryVaspId or beneficiaryWalletType. A request with both or neither is rejected.
Last modified on October 23, 2026