Unirail.dev – Plaid for Your Plaids

in 26 providers · 33 capabilities POST /v1/route_decisions fastest recommended cheapest one decision

Choose the provider for every payment by cost, speed and success rate

For each payment, bank link or identity check, Unirail tells your backend which of your providers to use, what it will cost under your contracts and why. It routes to Plaid, Yapily and Enable Banking today. Your backend can make the call itself with your own keys. Unirail never holds or moves money.

In Decide mode, the default for regulated platforms, Unirail makes the decision and your backend makes every provider call. Scroll to follow a £50.00 payment between two UK accounts from the first request to the outcome your backend reports back.

Before it moves money, links a bank or checks an identity, your backend sends Unirail a route decision request. This one is a £50.00 payment from a UK sort code and account number to a UK IBAN, asking for the recommended rail.

YOUR BACKEND PAYER'S BANK PAYEE'S BANK UNIRAIL · DECIDES ONLY MASKED REQUEST

What the request contains

Names, account numbers and contact details stay on your platform. Each account goes as a fingerprint you compute with your own HMAC key. Unirail can recognise the same account next time but can't reverse the fingerprint. It rejects any request with a field it doesn't expect, such as a name.

OPERATION

GB · GBP

5000

SCAN · IBAN

FP_…

NAMES ✕ ACCOUNT NUMBERS ✕ CREDENTIALS ✕ SENT TO UNIRAIL

What the decision contains

Unirail answers with the provider and rail to use, what it will cost under your own contracts, the ETA and how likely it is to succeed. You also get the ranked alternatives, the options it ruled out with a reason for each, the policy version and a digest you can bind your user's approval to.

DECISION · RAIL, COST, ETA, REASONS RECOMMENDED ALTERNATIVE RULED OUT · NO COVERAGE

Your backend calls the provider

@unirail/executor runs Unirail's provider adapters inside your own process. Your backend uses it to call Provider A with credentials from your own vault. In Decide mode those credentials never leave your platform.

With Execute via Unirail, Unirail makes this call for you using the credential from your vault.

YOUR VAULT YOUR BACKEND PROVIDER A YOUR KEYS STAY HERE PROVIDER CALL UNIRAIL · NOT ON THIS CALL

The payment moves between the banks

Provider A starts the payment under your contract. The £50.00 goes from the payer's bank straight to the payee's bank without passing through Unirail.

UNIRAIL · OFF THE PATH PAYER'S BANK → PAYEE'S BANK £50.00 · ACCOUNT TO ACCOUNT

Your backend reports the outcome

Your backend sends the rail it used, the status, the latency and the provider's fee to POST /v1/outcomes, with no names or account numbers. Unirail uses outcomes to track reliability for each rail, operation and bank. It also counts them against your contract for the billing period. The next decision is then priced at your current volume tier.

await unirail.outcomes.create({ decision: decision.id, rail: decision.rail, status: "succeeded", latencyMs: 1840, });

Updatesreliability per rail, operation and bank

Counts towardcontract usage this billing period

YOUR BACKEND PAYEE'S BANK RELIABILITY · CONTRACT USAGE OUTCOME · STATUS, LATENCY, FEE

What you get with Unirail

You keep your contracts with PISPs, aggregators and KYC vendors. Unirail adds these four things on top.

One API and SDK for all your providers

You set up Plaid, Yapily and Enable Banking in the dashboard. Your code calls the same SDK whichever provider handles the payment.

OIDC

Works with your Infisical vault

Provider credentials stay in your Infisical vault. Adding a provider doesn't add environment variables to your services.

Deal tracking for your provider contracts

Unirail keeps versioned fees, volume tiers and renewal dates for each provider contract and prices every decision with them. Before you renegotiate, you can see what each provider costs you and what switching would save.

A routing decision for every operation

Each decision lists ranked alternatives and gives a reason for every option it ruled out.

Unirail can route to Plaid, Yapily and Enable Banking today. The other 23 are listed for comparison only. For each one you can see what it covers in which country, with the source and the date it was checked, before you decide who to sign with.

Add the SDK to your backend, create a client with your test key and send a route decision request. Field names match the published v1 contract (RouteDecisionRequest, OutcomeRequest). Amounts are strings in minor units ("5000" is £50.00).

The SDK isn't on npm yet. We give you access to the package when we set up your account.

import { createUnirail, maskAccount } from "@unirail/sdk";

const unirail = createUnirail({ apiKey: process.env.UNIRAIL_SECRET_KEY });

const decision = await unirail.routeDecisions.create({ operation: "banking.pis.single", amount: { value: "5000", asset: "iso4217:GBP" }, payer: { country: "GB", scheme: "scan", accountRef: await maskAccount("payto://scan/040004/12345678", process.env.UNIRAIL_FINGERPRINT_KEY), }, payee: { country: "GB", scheme: "scan" }, preference: "recommended", });

if (decision.status === "routed") { // Your backend calls decision.rail with your own credentials (@unirail/executor), // then reports what happened so the next decision learns from it. const started = Date.now(); const result = await callProvider(decision); // your code await unirail.outcomes.create({ decision: decision.id, rail: decision.rail, status: result.ok ? "succeeded" : "failed", latencyMs: Date.now() - started, }); }

How Unirail handles your data and credentials

In Decide mode Unirail sees masked metadata only. With Execute via Unirail it reads each credential from your vault when it needs it and never writes one to disk or a database.

YOUR PLATFORM · DECIDE MODE

YOUR VAULT credentials names account numbers fingerprint key

UNIRAIL

masked metadata, masked outcomes

decision

Short-lived access to your vault

Unirail gets read-only access to one folder in your Infisical vault and keeps each credential in memory for up to five minutes. Revoking access stops new reads straight away.

Unirail stores only a hash and the prefix of each test and live key.

Your stored configuration is encrypted with a separate data key for each environment (AES-GCM envelope encryption).

Every webhook is signed under the Standard Webhooks scheme. The SDK checks the signature for you.

The control plane's database runs in Cloudflare's EU jurisdiction.

Read the security details Ask about self-hosting the decision engine

Start with a test key

Accounts are open by request while Unirail is in early access. We'll set yours up with a test key (ur_test_sk_…) and access to the SDK so you can send decisions from your backend. We haven't published pricing yet. Talk to us about it before you go live.