Skip to content
All solutions

Transaction and Crypto Gateway

One transaction model inside, an adapter per counterparty outside. It connects a provider to banks, a bank to providers, and a fintech to crypto platforms and custodians.

  • ISO 20022
  • SWIFT
  • Crypto connectivity

Overview

  • Formats and channels

    The gateway holds a transaction in one internal format and meets every counterparty in theirs. REST with JSON, ISO 20022 XML, a file exchange, or SWIFT where nothing else is offered: each attaches as an adapter, and the processing behind them does not change when one is added. On the ISO side it builds, receives and parses the full set, from pain to initiate a payment through camt for statements and investigations, validated against the schema before anything leaves.

  • Carrying a transaction

    A route through compliance, the core and the counterparty is set in configuration, and exceptions travel a route of their own and do not stall the main one. One identifier follows the transaction across every leg, with a UETR added on the SWIFT one. Statuses arrive from provider webhooks, bank messages, gpi Tracker and Universal Confirmations, each reporting differently, and resolve into a single state per operation.

  • Reaching crypto

    One internal contract covers exchanges, brokers and custodians, so a platform can be replaced without touching the product. Quotes come back with the price actually filled and orders route between venues with a fallback when one is unavailable. Wallets, signing policies and withdrawal controls are driven from here while the keys stay with the custodian, and on-chain deposits credit only after the confirmations the network requires.

  • Reconciliation and audit

    Statements match automatically, whether they arrive as camt.053 and camt.054 or as their API equivalents, and anything that does not match goes to review. The platform, the custodian and our own ledger are reconciled every day, and a discrepancy opens as an incident with an owner. Every message, status and routing decision is kept in a form a regulator can check.

Ownership

On us

  • The gateway itselfOne transaction model, an adapter per counterparty, and the orchestration between them.
  • Every integration after the firstEach one attaches as an adapter to the same model.
  • The evidence a reviewer asks forStatuses resolved to one state, investigations kept as cases, and a full audit trail.

On you

  • The relationshipsThe banks and platforms you already have. The gateway connects to them.
  • Your coreAnd whoever owns changes to it.
  • Your custodianAnd the signing policy you want enforced.

Fit

Who it is for
PSPs, EMIs and payment providers working with several banks. Banks opening a channel to providers. Banks and fintechs connecting crypto. Corporate treasuries.
When it comes up
Swift's move to structured addresses, which is deferred but not canceled. A new partner bank or crypto platform. Every integration written separately and taking a quarter. Dependence on a single platform.
The objections we hear
That the core vendor will do it, when a core carries minimal translation without statuses, investigations or an audit trail. And that connecting directly is simpler, when a direct connection ties you to one vendor's API changes and its downtime.

Limits

  • No correspondent network, and no SWIFT membership.

  • No core rewrite.

  • No keys held.

  • No local payment systems, market by market.

Related work