Pulling live rates, Wallet balances and FX orders out of Walutomat

Walutomat’s quoted rates refresh roughly every ten seconds, per its Play Store listing, and that tick is the centre of gravity for anyone integrating it. Underneath sits a multi-currency Wallet, a peer-to-peer exchange book, and a transfer rail that reaches 70 countries, per the operator’s product pages. Currency One S.A. runs all of it under a Polish payment-institution licence. So the data worth reading is real money state: per-currency balances, the orders that moved them, and a price feed that changes faster than most reporting systems poll.

This write-up maps what the app holds, the authorized way to read it for a consenting account, and the runnable client we hand over. The shape of the answer: anchor the money-movement fields on a consented account read, mirror the order book and the rate feed through authorized interface integration, and normalize both into one event stream your systems can consume.

What lives in a Walutomat account

Walutomat’s surfaces split into money state, trading state, and market data. Here is how they map to something an integrator can consume.

Reaching the Wallet and the order book

Consented account read (PSD2 / PolishAPI)

The Wallet is a payment account maintained by a licensed institution, which puts its balances and transfer history inside the account-information scope that PSD2 and the PolishAPI standard define. Reachable this way: per-currency balances and the money-in/money-out history, under a consent the user grants and can pull back. It is the durable route — regulated, versioned, stable across app releases. We set up the consent flow and the onboarding with the account holder as part of the build; where a given field is not carried on the standard account interface, we reach it through the route below rather than leaving a gap.

Authorized interface integration

The exchange order book, the live-rate feed, the currency alerts, and the finer transfer metadata live in the app’s authenticated session, not in the payment-account schema. We read these by analysing and re-implementing the app’s client traffic under your authorization — reverse engineering for interoperability, nothing more. The route tracks the app, so when a surface shifts we re-validate and version the client against it. This is what gives you the trading and market-data side a pure account read cannot.

User-consented access and native export

Where a user would rather authorize directly, or pull their own statements, we wire that as a fallback: a consented session or a user-initiated export, normalized into the same schema as the other two. Lower engineering load, lower freshness. Useful for backfill and reconciliation.

For most teams the combined read is the answer. Hang the money-movement fields on the consented account interface for durability, and layer interface integration over it for the order book and the ten-second rate feed. Together they cover the Wallet end to end. Apart, each leaves half the picture.

What lands in your repo

Everything is built around the surfaces you choose, and the first thing you receive is code that runs.

• A runnable Walutomat client in Python and Node.js, covering the picked surfaces — Wallet balance read, exchange-order history, the rate feed, and transfer status.
• A normalizing event consumer that turns settled transfers and rate ticks into one stable shape, idempotent so replays and duplicate ticks do not double-count.
• An automated test suite with recorded fixtures for the partial-fill order lifecycle and for balance reconciliation across currencies.
• A sync design stating, per surface, whether you mirror the feed in real time or sample it on a cursor, and why.
• An OpenAPI / Swagger description of every surface we map, so the client is not the only source of truth.
• A protocol and auth-flow report — the token, session, and refresh chain as it actually behaves on this app.
• Interface documentation plus consent and data-retention notes for whoever signs off on the integration.

A transfer event and a rate tick, normalized

Two surfaces, one shape. The snippet shows the event a consumer receives for a settled transfer and a single rate tick, plus the de-dupe both run through. Field names are illustrative and get confirmed against the live session during the build.

// One normalized shape for two Walutomat surfaces.

// 1) A wallet-to-wallet or international transfer, after it settles
const transfer = {
  id: "wt_8841207",            // Walutomat transfer reference
  type: "WALLET_OUT",          // WALLET_OUT | WALLET_IN | INTL_OUT
  walletCurrency: "EUR",       // one of up to 22 Wallet currencies
  amount: "1500.00",
  status: "SETTLED",           // PENDING | SETTLED | REJECTED
  counterpartyIban: "PL..",    // present for bank-bound transfers
  bookedAt: "2026-06-08T07:41:13Z"
};

// 2) A single tick off the rate feed (~every 10s, 44 pairs)
const tick = { pair: "EURPLN", bid: "4.2715", ask: "4.2761", at: "2026-06-08T07:41:10Z" };

// The consumer your handover ships. De-dupe on the transfer
// reference for money movement, on pair+timestamp for ticks,
// so a replayed settlement posts once and a repeated quote is dropped.
async function onEvent(evt) {
  const key = evt.id ?? (evt.pair + evt.at);
  if (await store.seen(key)) return;
  await store.mark(key);
  return evt.pair ? rates.record(evt) : ledger.post(normalizeTransfer(evt));
}

KNF, PSD2, and the consent the read stands on

Walutomat sits inside Poland’s open-banking regime: PSD2 as implemented in Polish law, the PolishAPI interface standard, and KNF as the supervisor. Currency One S.A. holds a KNF payment-institution licence — extended over time to cover money transfers and, more recently, account-information and payment-initiation services, per its own licence announcements. For our purposes the dependable basis for any read is narrower and simpler: the account holder’s explicit authorization. A PSD2 account-information consent is scoped to named data, carries a fixed lifetime, and can be revoked by the user at any time; we build to that grant rather than around it. Personal data in the Wallet — names, IBANs, transaction detail — falls under GDPR, so the handover is data-minimized to the fields you actually use, access is logged against the consent record, and we work under an NDA where the engagement needs one. Nothing here depends on a credential the user has not knowingly handed over.

What we account for on this build

Three things about Walutomat shape how we write the client.

Partial fills are the normal case

Walutomat fills an exchange order by matching one user’s offer against others, so a single order can settle in several legs at slightly different rates. We model each order as a parent with its child fills, so a downstream ledger sees one weighted-average rate plus the underlying legs — not a guessed single price.

Balances are per-currency, not one number

Funds sit in separate pots, up to 22 currencies, each with its own minor-unit scale. We carry every currency as its own line and only fold to a reporting currency at the edge, using a rate you control, so a zero-decimal currency never rounds into a two-decimal one.

PLN pairs and cross pairs follow different conventions

Some pairs quote against the złoty (EURPLN, USDPLN); others, like EURUSD, never touch it. We carry the quote convention per pair so a cross-pair order is not mis-scaled against a PLN balance. And where a business account exposes its own EUR IBAN for incoming payments, we map that as a distinct funding surface, arranged with the account holder during onboarding.

Cost, and how the work runs

What you get first is runnable code for the surfaces you pick — a working Walutomat client, its tests, and the docs — delivered in one to two weeks. You can take it as source you own, from $300, invoiced only after delivery once you have checked it does what you asked. Or skip hosting entirely and call our endpoints, paying per call with nothing up front. Either way the client only provides the app name and what they need from its data; access and the compliance paperwork are arranged with you as the project runs.

Tell us what you need from Walutomat

Where teams wire this in

Walutomat shows up in a handful of recurring integrations.

• Treasury sync. Per-currency Wallet balances into an ERP, refreshed on each transfer event and reconciled nightly, folded to a reporting currency only at the boundary.
• FX cost reporting. Filled exchange orders with their match legs, so finance can compare the effective rate against mid-market and see the spread the marketplace actually delivered.
• Salary-in-EUR flow. Follow an incoming EUR transfer into the Wallet, the exchange to PLN, and the payout to a bank account — each leg reconciled, end to end.
• Alert mirroring. Reflect a user’s rate alerts in your own product and act on the trigger, instead of asking them to watch two apps.

Screens we mapped against

The app’s own screens — the Wallet, the exchange view, the rate list — are the surfaces the client targets. Open any to enlarge.

What we checked, and where

This mapping is built from Walutomat’s product and help pages, Currency One’s licence announcements, and Poland’s open-banking documentation, read in June 2026. We confirmed the Wallet and transfer mechanics against the operator’s how-it-works material, the KNF licensing history against Currency One’s own statements, and the consent path against the PolishAPI standard. Where a detail was not public — exact internal field names, session specifics — it is flagged as confirmed during the build, not guessed here.

Sources: How Walutomat works, Currency One’s payment-institution licence, the AIS/PIS licence extension, the PolishAPI standard.

OpenFinance Lab · interface assessment, June 2026.

Other FX and transfer apps in the same orbit

Walutomat shares its category with a cluster of exchange and money-transfer apps, each holding comparable per-user balance and transaction state — useful context for a unified integration.

• Conotoxia (Cinkciarz.pl) — Poznań-based multi-currency platform with exchange, transfers, cards and a wallet; holds per-user balance and transaction records.
• InternetowyKantor.pl — also operated by Currency One; online exchange across roughly 19 currencies to ~45 countries, with a comparable wallet and transfer shape.
• Kantor.pl — online exchange office with account balances and transfer history behind login.
• TOPkantor — online currency exchange built around a funded account and order records.
• Wise — multi-currency account and international transfers, with detailed per-transaction and balance data via a consented connection.
• Revolut — multi-currency wallet, FX and cards; rich authenticated account and transaction records.
• Curve — card-aggregation wallet that consolidates spend across linked cards into one transaction stream.
• Alior Kantor Walutowy — a Polish bank’s exchange service with FX orders and account balances behind authentication.

Questions integrators ask about Walutomat

Walutomat refreshes rates every few seconds — do you stream them or poll?

Either, and we decide per use case. The published quote moves about every ten seconds across 44 pairs, so for live pricing we run a push consumer that hands your system each new tick; for reporting or backfill we sample on a cursor at a slower interval so you store only the points you need. The client ships with both wired and a switch between them.

Which Wallet fields come through regulated consent, and which through interface integration?

The money-movement fields — per-currency balances and the transfer history — map cleanly onto a PSD2 account-information consent, since the Wallet is a payment account under Currency One’s KNF licence. The exchange order book, the currency alerts, and the live-rate feed sit outside standard payment-account scope, so we read those through authorized interface integration against the consenting user’s session. The handover normalizes both into one schema.

Walutomat matches your offer against another user’s — how does that show up in order data?

An exchange order can fill in several legs at slightly different rates as it matches counterparties, so we model each order as a parent with its child fills. Downstream you get one weighted-average rate plus the underlying legs, rather than a single price that hides how the order actually executed.

Balances span up to 22 currencies — how do you keep them from colliding in reporting?

Each currency stays its own line with its own minor-unit scale, so a zero-decimal currency and a two-decimal one never round into each other. We only fold to a single reporting currency at the edge, using a rate you control, which keeps the source balances exact and auditable.