Security

The below security mechanisms are implemented in order to protect communications from eavesdropping and tampering, authenticate and authorise clients, as well as provide non-repudiation for communicated financial instructions. Unless otherwise specified, these mechanisms shall apply equally to the implementations of both the Electrum-side API (for calling Electrum) and the partner-side API (for receiving Electrum calls).

TLS

All HTTP sessions shall be TLS encrypted, as negotiated between the HTTP client and server. The minimum supported version is TLS v1.2. TLS Mutual Authentication is not supported.

HTTP message signing

All HTTP messages (both requests and responses) shall contain a signed JWT token placed in the x-jwt-signature header. This token is the primary authentication method, and in addition to authentication of the client also ensures message contents are tamper-resistant, and offers a high level of confidence that a message was authentically sent by the claimed sender. This protects both the corporate client and the bank.

See more details on how to sign HTTP messages in the HTTP Message Signing section.

OAuth

Some banks may additionally require that a valid OpenID Connect (OIDC) access token issued by the bank's authorisation server be placed in the Authentication header as a bearer token. This ensures that an authenticated session always exists directly between you and the bank (not Electrum). OAuth only applies to the Electrum-side API, not the partner-side API. You will be required to periodically obtain a new token using the Client Credentials grant (sometimes also known as machine-to-machine) flow. Typically, tokens are valid for up to 120 minutes. It is recommended that you request a new token when 50% of the token lifetime has elapsed to ensure that systems may recover from brief outages.