CryptoSwift-to-Partner Transactions (Custom Integration)

This page covers the CryptoSwift -> Partner direction: CryptoSwift sends a Travel Rule message to the partner's network.

For CryptoSwift -> Partner messages, each partner can define its own API specification, payload contract, identifiers, authentication scheme, and lifecycle semantics. CryptoSwift will build the integration layer that adapts CryptoSwift-originated messages to the partner's native setup.

This custom contract usually covers:

• endpoint URLs and authentication headers
• VASP and transaction identifiers used by the partner network
• encrypted IVMS101 payload format
• transaction metadata fields such as asset, amount, blockchain, origin, destination, and transaction hash
• response shape, retry behavior, and error handling
• any callback or webhook contract used by the partner network

Our strongly preferred methodology is for the partner to mirror CryptoSwift's native Partner API models as closely as possible. In other words, the custom CryptoSwift -> Partner contract should look similar to the standardized Partner -> CryptoSwift API where possible. Matching the same entity, transaction, and IVMS101 envelope structure reduces mapping ambiguity, shortens implementation time, and makes cross-network troubleshooting significantly simpler.

The most important area to align is encryption.

To minimize security risk and transaction latency, the partner should mirror CryptoSwift's asymmetric libsodium protocol. The expected model is crypto_box_easy using Curve25519 keys translated from Ed25519 keypairs.

In the CryptoSwift -> Partner direction, the partner acts as the receiving VASP or receiving network:

• CryptoSwift encrypts with CryptoSwift's sender private key and the partner receiver public key.
• The partner decrypts with its own receiver private key and CryptoSwift's sender public key.
• The encrypted payload remains peer-to-peer across both network boundaries without exposing IVMS101 personal data to intermediate systems.

This keeps the security model consistent with the standardized Partner -> CryptoSwift API and avoids a separate cryptographic contract for each direction. It also lets both networks reuse key management, nonce handling, ciphertext format, and verification procedures already used by the standard Message Encryption Protocol.

When a partner cannot mirror the CryptoSwift encryption model, document the alternative precisely in the custom API specification. Include key formats, nonce handling, ciphertext encoding, replay protection, and the exact plaintext schema before encryption.