🇪🇺 Predictable egress for open banking

🇪🇺 Static IP for TrueLayer

TrueLayer is the secure pipe between your app and your users' banks, and integrations like that get audited. Send every truelayer.com payment and data call out through two static EU IPs your security review can sign off on.

payments service (Python)

# picked up by requests automatically

HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443

requests.post('https://api.truelayer.com/v3/payments',

    headers={'Authorization': f'Bearer {token}'},

    json=payment_payload)

Open banking egress gets scrutinized

TrueLayer never sees your users' bank credentials, which is exactly why everyone downstream asks hard questions about the traffic your side of the pipe sends.

Security reviews ask for your source addresses

Before a bank, partner, or enterprise customer connects to your product, their questionnaire asks which address ranges your systems call from. Answering "wherever the platform decides" ends the conversation badly.

Allowlisting is recommended, rotation makes it impossible

TrueLayer's own security best practices tell you to implement IP whitelisting where possible. Serverless and container platforms hand your backend a different egress on every deploy, so the address you registered yesterday is stale today.

A payment is a conversation, not a call

You create the payment at /v3/payments, poll its status while the user authorizes in their banking app, and reconcile from the webhook handler. Those steps often run in different services and environments, each with its own exit address, and inconsistency is what monitoring and audits notice first.

Sandbox and production, two exits to govern

Test traffic heads to api.truelayer-sandbox.com while live payments go to api.truelayer.com. Keeping the two straight in firewall rules, alerting, and audit logs gets simpler when both leave through one address pair you control.

The Solution

One registered exit for everything you send to TrueLayer

Your backend

payment + data services

HTTPS Proxy

(Static EU IP)

api.truelayer.com

payments + data API

Payment creation, status polling, token refresh, data pulls: whatever leaves your infrastructure toward TrueLayer carries the same two European addresses. One is the spare tire for the other, so the pair you registered is always the pair in use.

Declare HTTPS_PROXY once per environment and Python services inherit it; Node services pass a single dispatcher.
Both addresses in the account cover each other, so the second answers instantly if the first pauses and no security alert fires.
Bearer tokens and payment payloads cross the proxy still encrypted; TLS terminates at TrueLayer, nowhere earlier.

Why open banking teams pick OutboundGateway

Answers the questionnaire

A concrete pair of addresses to write into the security review, replacing a paragraph about how cloud egress works.

Fits every runtime you use

Python picks the proxy up from the environment, Node attaches it as a dispatcher, containers get it as an env file. Same two IPs everywhere.

European exits

Traffic to a PSD2 platform leaves from EU data centres, which keeps the residency description in your documentation short and true.

Designed for

Teams building on TrueLayer who need their side of the connection to look as disciplined as the platform they are calling.

Payment startups

Products initiating open banking payments where the bank or acquirer onboarding call includes a field for your outbound address ranges.

Data and verification apps

Account aggregation, KYC-style verification, and Signup+ flows that pull sensitive financial data on a schedule from every environment you operate.

Regulated and audited teams

PSD2-adjacent operations whose penetration tests and compliance audits expect controlled, documented egress for every third-party financial API.

Multi-environment platforms

SaaS running staging, sandbox, and production side by side, where one address pair collapses three sets of firewall exceptions into one.

Implementation

Point your existing HTTP stack at the proxy and every request to api.truelayer.com changes origin.

Python: nothing to change

The requests library reads HTTPS_PROXY from the environment on its own. Export the variable where your payment service starts and this code already routes through your fixed IP.

import os
import requests

resp = requests.post(
    "https://api.truelayer.com/v3/payments",
    headers={"Authorization": f"Bearer {os.environ['TL_TOKEN']}"},
    json={
        "currency": "EUR",
        "payment_method": {
            "type": "bank_transfer",
            "provider_filter": {"countries": ["DE"]},
        },
        "amount_in_minor": 2500,
    },
    timeout=30,
)
# HTTPS_PROXY from the environment is applied automatically

Node: one dispatcher

With undici, attach the proxy as a dispatcher and every fetch in the service uses it.

import { fetch, ProxyAgent } from "undici";

const dispatcher = new ProxyAgent(process.env.HTTPS_PROXY);

const res = await fetch("https://api.truelayer.com/v3/payments", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.TL_TOKEN}` },
  body: JSON.stringify(payment),
  dispatcher,
});

Declare it once per environment

Keep credentials out of the file; load them from the environment or your secret store.

# docker-compose.yml
services:
  payments-api:
    build: .
    env_file: .env   # HTTPS_PROXY=..., TL_TOKEN=...

# Kubernetes
env:
  - name: HTTPS_PROXY
    valueFrom:
      secretKeyRef:
        name: outboundgateway
        key: proxy-url

Write both addresses into the review

Each account carries two static European addresses and the second exists to take over without ceremony. Name the pair in your security questionnaire and your firewall rules: whichever node is serving, the source your partners observe never leaves that list.

📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.

European egress for financial data

Open banking traffic carries account details and payment instructions. Regulators and counterparties care about where that traffic travels.

GDPR-conscious routing

Requests carrying personal financial information leave through European data centres, which keeps your processing records straightforward.

TLS straight through

The proxy forwards sealed traffic to TrueLayer without terminating it, so tokens, consent references, and payment payloads stay private end to end.

What you get

A registered address pair

Two European IPs, one standing behind the other, so the pair in your paperwork is always the pair in use.

Drop-in for your stack

One env var for Python, one dispatcher for Node, one env file for containers. No SDK fork, no wrapper library.

End-to-end encryption

Sealed TLS passes through untouched; the proxy can read neither token nor payload.

European data centres

Egress inside the Union for a platform operating under Europe's PSD2 regime.

Consistent across environments

Staging, sandbox, and production all report the same source, which makes alerts and audit logs legible.

Honest pricing

Starting from €19/month. Flexible plans for every scale. Cancel anytime.

Give your integration a fixed address

Fill the source-address field of your next security questionnaire in one line: two static EU IPs, failover included, every TrueLayer call behind them.

Starting from €19/month. Flexible plans for every scale. Cancel anytime.

Frequently asked questions

Does TrueLayer block requests from unknown IP addresses?

Not as a documented per-credential restriction. The reason teams still pin their egress is the opposite direction: TrueLayer's security best practices recommend implementing IP whitelisting, and your own reviewers, banking partners, and auditors expect a controlled, declared source range. A fixed address pair satisfies that expectation regardless of which side enforces it.

Does this work for both sandbox and production endpoints?

Yes. Requests to api.truelayer-sandbox.com and api.truelayer.com are both ordinary outbound HTTPS, so the same proxy setting covers test and live traffic. Keeping them behind one address pair also means your logs and firewall rules treat the two hosts consistently.

What about the webhook side of the payment flow?

Webhooks from TrueLayer arrive inbound at your public endpoint and do not traverse the proxy; what the proxy governs is everything you send out, including creating payments, polling status, refreshing tokens, and pulling account data. Restricting your webhook endpoint to known TrueLayer source ranges is a separate, complementary step on their documentation.

Integration review coming up?

Happy to talk through your TrueLayer setup, your environments, and how a fixed EU pair reads in your security documentation.

Contact Our Founders →