How Unirail handles your provider credentials and data
Unirail doesn't store your provider credentials. In Decide mode it never reads them, because your backend calls the provider. In Execute mode it reads them from your own Infisical through OIDC federation and keeps them in memory for at most five minutes.
Where your provider keys go
The diagram shows the same provider call in both modes. In Decide mode the credentials never pass through Unirail. The steps below the diagram apply to Execute mode.
Execute via Unirail
Your Infisical
Folder /unirail holds the provider keys. A machine identity for Unirail can read only that folder.
OIDC issuer
api.unirail.dev/oidc signs a token for your organisation and environment.
In memory during the call
Values stay in the memory of the instance making the call for at most five minutes. They're never written to a database or logged.
Plaid, Yapily or Enable Banking
Unirail calls it under your own contract with the provider.
Decide mode
Your vault and your backend
@unirail/executor reads the keys and calls the provider itself. Unirail gets masked metadata and outcomes, never a key.
The same provider
Your backend calls it through the same adapters Unirail runs.
-
You create a machine identity in Infisical with OIDC auth, bound to Unirail's issuer and to your organisation and
environment as the subject, read-only on one folder (
/unirailby default). - When an instance needs your credentials and holds no fresh copy, Unirail signs a short-lived token as that issuer and exchanges it at Infisical for an access token.
- Unirail reads the folder and holds the values in the memory of the instance making the call, for at most five minutes. They're never written to a database or key-value store. They're never logged, traced or included in an error message.
- When you check the connection in the dashboard, Unirail lists the folder and reports the key names it found but not the values. If you delete the machine identity, the next exchange will fail.
How each part is protected
-
Credentials read from your vault through OIDC
Unirail runs its own OIDC issuer at https://api.unirail.dev/oidc. Your Infisical machine identity trusts that issuer read-only on one folder. Unirail exchanges a signed token for a short-lived Infisical access token and keeps the credentials in memory only.
-
Decide mode sends no names or account numbers
Decide requests carry the operation, countries, currency, the amount or an amount band, bank ids, account types and account fingerprints you compute with your own HMAC key. Unirail can't reverse a fingerprint.
-
API keys are stored as hashes
Unirail shows each test and live secret key (ur_test_sk_…, ur_live_sk_…) once. It stores only a SHA-256 hash of the key and a short prefix for display.
-
Encrypted configuration
Stored configuration is encrypted with AES-256-GCM under a separate data key for each environment. A master key derived from a server secret wraps each data key. Each ciphertext is bound to its row and purpose and won't decrypt if it's moved anywhere else.
-
Signed webhooks
Webhooks are signed with the Standard Webhooks scheme. The SDK verifies the signature for you.
-
Idempotent writes
Every write accepts an Idempotency-Key. A retried request with the same key can't create a second payment.
-
EU data residency
The control plane's database runs in Cloudflare's EU jurisdiction.
-
Self-host the decision engine
If you run @unirail/router in your own infrastructure (by arrangement), routing requests and decisions stay in your network. Only the outcomes you report reach Unirail.
Certifications and audits: Placeholder
What Unirail holds in each mode
Decide mode
For each decision Unirail keeps only what it needs to match outcomes to it: the decision id, operation, chosen provider, country, bank id, digest, policy and snapshot versions and the times it was made and expires. It also holds the outcomes you report (status, latency, an optional fee and a short failure code), your routing policy and the deals you enter. It never holds names, account numbers or provider credentials.
Read more about Decide mode and what the metadata can still reveal.
Execute via Unirail
Unirail calls the provider for you and handles the full request for bank links, route quotes and payment intents. It stores account addresses encrypted and fingerprinted. The API only returns them masked. Your users' provider consent tokens are stored with envelope encryption and never returned through the API.
That makes Unirail your processor for this personal data. It needs a data processing agreement between us.
Limits we know about
- In Execute mode, credential values sit in a Unirail instance's memory for up to five minutes. Revoking the grant stops new reads but doesn't clear values already in memory.
- A fresh instance adds one round trip to Infisical before its first provider call, roughly 100 to 300 ms in the EU.
- If Infisical is unreachable, fresh instances refuse new operations. Instances that already hold values keep working until those values expire.
- Infisical is the only vault Unirail supports today.
- Decide mode still shares metadata. Over time, operations, countries, amounts or bands, banks and outcomes build a picture of your volume. To limit that, send amount bands or self-host the routing engine.
- There's no public status page yet. Placeholder
Common questions
Does Unirail store our provider credentials?
Unirail never writes them to disk or a database. In Decide mode it never sees them. In Execute mode it holds them in memory for at most five minutes after reading them from your Infisical.
How do we revoke Unirail's access to our vault?
Delete the Infisical machine identity you created for Unirail. The next token exchange will fail and Unirail won't be able to read the folder again. Values an instance already holds in memory expire within five minutes.
What could a compromised Unirail do in Decide mode?
It could return a bad decision, such as an expensive or slow provider. It couldn't move money, read accounts or replay a payment, because it holds nothing that authorises one. Your executor only pays through providers you've configured with your own credentials. A bad choice would show up in the decision's alternatives and reasons.
Is Unirail regulated?
Unirail isn't the regulated party. It never holds or moves funds. Your platform keeps its own licences, its own contracts with PISPs, aggregators and KYC vendors and its own KYC, AML, sanctions and record-keeping duties.
Where is our data stored?
The control plane's database runs in Cloudflare's EU jurisdiction. Provider credentials aren't stored anywhere in Unirail.
How do we check a webhook came from Unirail?
Webhooks follow the Standard Webhooks signing scheme. Call webhooks.verify from @unirail/sdk with your endpoint's signing secret before you act on one.
Take this to your security review
Send us your review questions and we'll answer them in writing. You can also request early access and test the boundary yourself.