The cardholder data behind a Currensea travel card, and the authorized route to it

A Currensea card spend produces two amounts at once: the local-currency figure at the merchant and the GBP that will leave your bank, converted at what Currensea calls the Realtime Rate. That paired record, plus an automatic per-transaction saving versus a high-street bank, is the asset an integrator usually wants here — not a wallet balance, because there is no wallet. Currensea links to an existing UK current account through open banking and settles each spend by Direct Debit, so the money sits in the cardholder's own bank the entire time.

Bottom line: the valuable, Currensea-specific data is the converted-spend stream and the savings ledger; the underlying account behind it is reachable on its own through regulated account-information consent. We would build both together — open banking for the regulated bank-account spine, consented interface analysis for the Currensea-only conversion and savings fields that the bank account never sees.

What Currensea holds on a cardholder

Each row below is a real surface the app or its open-banking link exposes, named the way Currensea presents it.

Two routes that fit Currensea, and the one we would take

Open banking account-information consent

The bank account that funds the card is itself reachable. As a registered Account Information Service Provider under the FCA's Payment Services Regulations, a consented connection returns the underlying account's balance and transactions — including the Direct Debit collections Currensea raises. This route is durable: it is regulated, token-based, and refreshable. Access is arranged with you during onboarding; the build runs either through a partner AISP or a provider you already work with, and we handle the third-party-provider registration and the consent screens as part of the engagement.

Consented interface analysis of the Currensea app

The conversion layer is Currensea's own. The Realtime Rate that was applied, the automatic saving, the plan tier, and the eSIM allowance are rendered by the app and do not appear in the underlying bank feed. We map the app's authentication and token refresh and the JSON it draws those screens from, working against a consenting account under your authorization. Effort is moderate; the durability caveat is honest — when the app front end changes, the parsing needs a re-validation pass, and we build that pass into maintenance.

Native export as a low-maintenance fallback

Where a statement or CSV export exists, normalizing it gives a coarse but stable feed that survives app changes. It loses per-transaction rate detail, so we treat it as a backstop, not the spine.

What we would actually recommend: run the open-banking consent as the regulated backbone for settled cash movement, and layer the consented interface feed on top for the Realtime Rate and savings fields that only Currensea computes. One gives you durability and a clean legal basis; the other gives you the numbers a travel-spend product is actually built around. The export route stays in reserve for clients who want a feed that needs almost no maintenance.

What you get from us

Everything below is scoped to Currensea's real surfaces, not a generic kit.

• An OpenAPI/Swagger specification covering the converted-spend ledger, the per-transaction Realtime Rate and savings fields, plan/profile, and the open-banking account read.
• A protocol and auth-flow report: the Currensea app's token acquisition and refresh, plus the AIS consent and 90-day reauthentication chain for the underlying account.
• Runnable source for the key endpoints in Python and Node.js — pull transactions, normalize the dual-currency record, reconcile against Direct Debit collections.
• Automated tests, including fixtures for multi-currency rows and plan-tier rate differences.
• Interface documentation and data-retention guidance written for an FCA-regulated data flow.

A worked example: the dual-currency transaction feed

Field names below are illustrative and are confirmed against a consenting account during the build; the shape reflects what the app screens render.

POST /oauth/token            # refresh an expired session
  grant_type=refresh_token
  refresh_token=<stored>
  -> { "access_token": "<jwt>", "expires_in": 900 }

GET  /v1/card/transactions?from=2026-05-01&limit=50
  Authorization: Bearer <jwt>

200 OK
{
  "items": [
    {
      "id": "txn_8f21",
      "bookedAt": "2026-05-12T19:04:33Z",
      "merchant": "PADARIA LISBOA",
      "currency": "EUR",
      "amountLocal": 14.80,
      "amountGBP": 12.71,
      "realtimeRate": 1.1645,
      "schemeRateEstimate": 1.1402,
      "savingGBP": 0.27,
      "plan": "PRO",
      "settlement": {
        "method": "DIRECT_DEBIT",
        "mandateRef": "CSEA-DD-...",
        "linkedAccountId": "acc_2"
      }
    }
  ],
  "nextCursor": "..."
}

# Error handling the client must cover:
#  401 invalid_token        -> run the refresh call above, retry once
#  409 consent_expired      -> trigger AIS reauthentication (SCA), pause sync
#  423 account_relink       -> linked bank account needs re-consent in app

The reconciliation step pairs settlement.mandateRef and linkedAccountId with the Direct Debit lines the open-banking read returns, so the integration reports settled cash, not a projected figure.

Where this integration pays off

• A travel or expense product that wants spend in the merchant's currency and in GBP on one line, with the FX cost already attributed.
• A personal-finance aggregator that shows a Currensea cardholder their real bank balance next to their converted travel spend.
• A savings or rewards dashboard that surfaces the cumulative FX saving Currensea computes, without rebuilding the rate model.
• An accounting export that needs Direct Debit settlement matched to the originating card transaction for clean reconciliation.

Consent and the FCA framework that applies

Currensea operates under the Financial Conduct Authority's Payment Services Regulations, the UK implementation of PSD2; the Open Banking Limited register lists it as having launched the UK's first customer-facing Card Based Payment Instrument Issuer offering. The underlying-account route runs on explicit account-information consent: the cardholder authorises a specific, time-bound read through their own bank's strong-customer-authentication screens, and that consent expires and must be renewed (the familiar 90-day reauthentication). Currensea itself never receives the bank login, and neither do we. The consented interface route operates only against an account whose holder has authorised the work in writing within the engagement. We log data access, keep consent records for audit, minimise to the fields a use case needs, and work under an NDA where the client requires one. That is how the studio operates, not a gate the reader has to clear first.

Things we account for on a Currensea build

These are specific to this app and are handled by us, not handed to you as conditions.

• No balance to read. Settlement is by Direct Debit from the linked bank, so there is no Currensea cash position. We reconcile the transaction feed against the matching collections in the underlying account so the integration reports a true settled figure.
• Plan-tier rate divergence. As currensea.com describes it, Essential carries a 0.5% markup, Pro and Elite are 0% on the 16 major currencies, and non-major currencies use the Mastercard rate plus 0.5%. We model the rate per plan and per currency class so the Realtime Rate and the savings figure reconcile rather than being assumed.
• Multiple linked accounts. A cardholder can link more than one UK bank account. We key the model by linked account so each Direct Debit collection routes to the right place in a sync.
• Consent-refresh timing. The open-banking read expires on the 90-day reauthentication cycle. We design the sync around that window and alert ahead of expiry so the feed does not stop silently.

App screens we worked from

Store screenshots used while mapping the surfaces above. Select to enlarge.

What was checked, and against what

Surfaces and the regulatory framing were checked in May 2026 against Currensea's own how-it-works page, the Open Banking Limited regulated-provider listing, the FCA's open-banking pages, and Mastercard's account of the Currensea open-banking debit card. Sources opened: currensea.com — how Currensea works; Open Banking Limited — Currensea Limited; FCA — open banking and the FCA; Mastercard Newsroom — Currensea open-banking debit card.

Compiled by the OpenBanking Studio integration desk · mapping reviewed 2026-05-16.

Other cards in the same integration neighbourhood

Same category, mentioned to widen the picture, not to rank anyone. Each holds account-level data a unified integration could normalise alongside Currensea.

• Wise — multi-currency account and card; holds balances per currency, conversions at the mid-market rate, and a transaction history an aggregator would sync.
• Revolut — multi-currency wallet with cards, holding per-currency balances, FX conversions and categorised transactions.
• Curve — a single card that routes to a linked underlying card or account; holds an aggregated transaction stream across the cards behind it.
• Starling Bank — a fully licensed UK bank; holds current-account balances, transactions and fee-free overseas spend records.
• Monzo — UK bank with real-time spend notifications, categorisation and budgeting data at the transaction level.
• Chase UK — current account with fee-free foreign spend; holds balances, transactions and cashback records.
• Barclaycard Rewards — a credit card with no overseas fees; holds statements, transactions and reward balances.
• HSBC Global Money — a multi-currency hold-and-spend account; holds per-currency balances and transfer history.

Questions integrators ask about Currensea

Currensea settles by Direct Debit, not a top-up balance — what does the data actually show?

There is no Currensea wallet to read. The data is a transaction ledger: each card spend or ATM withdrawal carries a local-currency amount, a GBP amount, the Realtime Rate that was applied, and an automatic savings figure. We reconcile that feed against the Direct Debit collections in the underlying bank account so the integration shows a true settled position rather than a notional balance.

Can the bank account sitting behind a Currensea card be read as well?

Yes. The user's underlying UK bank account is reachable as a regulated account-information consent under the FCA's Payment Services Regulations, accessed through a registered AISP. We run the consent flow and the third-party-provider onboarding as part of the build, so balances and transactions on the real account can be synced alongside the Currensea card layer.

Do the Realtime Rate and the savings number come through per transaction?

They do. The app renders both the local and GBP amounts and an automatic saving for each transaction. We model the rate logic by plan tier — as currensea.com describes it, Essential carries a 0.5% markup while Pro and Elite are 0% on the major currencies, with non-major currencies on the Mastercard rate plus 0.5% — so the per-transaction rate and the cumulative savings reconcile instead of being approximated.

We mostly issue cards on Pro accounts — does the plan tier change what an integrator gets?

The transaction and savings shape is the same across Essential, Pro and Elite. What differs is the FX markup and the perk ledger: Pro and Elite carry a FlexiRoam eSIM data allowance (per Currensea's plan pages, 3GB on Pro and 5GB on Elite). We expose plan tier and, where present, the remaining eSIM allowance as fields so plan-aware logic works without a second integration.

One plain note on working together: you can take source delivery — runnable code, the spec, tests and interface docs for the surfaces above, from $300, billed after delivery once you are satisfied — or use our hosted endpoints and pay per call with nothing upfront. Either way, a working build is normally one to two weeks. Tell us the data you want from Currensea through our contact page; access and compliance paperwork are arranged with you as part of the work.