Reaching Siirto's payment flows as the app folds into Nordea Mobile

Siirto's standalone app is on its way out. The separate listing under fi.nordea.mep.p2p — per its Google Play and App Store pages — was being wound down at the end of May 2026, with the transfer service moving inside the Nordea Mobile app during the spring. Sources covering the change put the date at 27 May 2026; either way, by the time you read this the icon above points at a product whose flows now live somewhere else. For an integrator that is the whole point: the data did not vanish, it relocated, and reaching it means connecting to where Siirto transfers actually settle rather than to a binary that no longer ships.

What Siirto carries is small-value, high-frequency money movement. Send to a phone number, swipe, and the amount leaves one Finnish bank account and arrives in another in real time. Requests for money, QR payments at a flea-market stand or coffee cart, and a chat-styled history of who paid whom all sit on top of that. The records a business wants to read are the transfers and requests, keyed to participants and timestamps — and because the rail runs around the clock, the right shape for reading them is a stream you can replay, not a batch you pull once a night.

What Siirto holds, surface by surface

None of these is exotic. They are the records any account-to-account payment product keeps, named the way Siirto names them. The work is reading them under proper authorization and normalising the per-bank differences away.

Authorized routes into Siirto's flows

Consented account information (the route we recommend)

Siirto money lands in a Finnish bank account, and that account is reachable through a PSD2 account information connection once the holder consents. This is the durable path: it survives the standalone app's retirement because it reads the settlement side, not the app UI. It returns the transfers and balances that correspond to Siirto activity, scoped to what the user authorizes, and it is the route a regulator expects you to use. Effort is moderate — consent onboarding plus per-bank field mapping — and durability is high.

Protocol analysis of the in-app traffic

Where a build needs surfaces the bank feed does not expose cleanly — request state, the conversation threading, QR references — we analyse the authenticated traffic of the client under the account holder's authorization and document the request, token, and response shapes. This reaches more of Siirto's own model. It is more fragile across client versions, and with the move into Nordea Mobile the relevant client is now that app rather than the discontinued standalone one. We treat it as a complement to the consented feed, not the spine.

User-consented credential access and native export

For one-off migrations, a consenting user can authorize a session that walks their own history and exports it. It is the lightest to stand up and the least durable; useful for a backfill or a proof of value, not for a live sync. We say plainly which of these we would build first: the consented account-information connection carries the load, with protocol analysis filling the gaps the feed leaves.

A worked example: streaming Siirto transfers with replay

The snippet below is illustrative — the exact field names get pinned during the build against the consenting bank — but it shows the shape we ship: a long-running consumer that reads settled transfers as a stream, remembers its offset, and replays safely after an interruption. Idempotency rides on the settlement id so a re-read never posts twice.

# Illustrative consumer for Siirto-settled transfers via a consented bank feed.
# Field names confirmed during the build; offsets persisted between runs.

class SiirtoStream:
    def __init__(self, feed, store):
        self.feed = feed            # consented account-information connection
        self.store = store          # durable offset + dedup store

    def run(self):
        cursor = self.store.last_offset() or "0"
        for evt in self.feed.transfers(since=cursor):   # 24/7, resumes from cursor
            self.handle(evt)
            self.store.commit_offset(evt["offset"])

    def handle(self, evt):
        sid = evt["settlement_id"]                       # stable, bank-issued
        if self.store.seen(sid):                         # replay-safe
            return
        record = {
            "settlement_id": sid,
            "direction":     evt["direction"],           # credit | debit
            "amount_minor":  evt["amount_minor"],        # cents, integer
            "currency":      evt.get("currency", "EUR"),
            "counterparty":  evt["counterparty_alias"],  # phone-derived, masked
            "settled_at":    evt["settled_at"],          # ISO 8601, real time
            "kind":          evt.get("kind", "transfer"),# transfer | request | qr
        }
        self.store.upsert(record, key=sid)               # idempotent write

# On restart: run() resumes from last_offset(); seen() drops anything re-read.
# Backfill: point `since` at "0" and let dedup absorb the overlap.

What lands in your repo

We hand over code that runs, ranked by what you will use first:

• A runnable consumer in Python or Node.js: the stream reader above, wired to the consented feed, with offset persistence and replay built in.
• Event handlers for the surfaces you care about — incoming transfer, request settled, QR collection — each with the idempotent write path so a re-run is harmless.
• An automated test harness with recorded fixtures of the transfer and request shapes, so a change in a field name shows up as a failing assertion before it reaches your sync.
• A sync design note covering continuous-stream versus backfill, where the cursor lives, and how reconciliation closes the gap after downtime.
• An OpenAPI / Swagger description of the normalised surface your services consume, plus a protocol and auth-flow report (the OAuth / token / consent chain as it applies to the connecting bank).
• Interface documentation and a short data-retention note, so the next engineer inherits the reasoning, not just the files.

Consent and the Finnish rulebook

Reading a Finnish bank account on a user's behalf falls under the Payment Services Act (amended by Act 898/2017, in force from January 2018, per the regulator's framework page) and is supervised by Finanssivalvonta, the Fin-FSA. Account information is read only with the holder's explicit consent and strong customer authentication; consents are time-bounded and revocable. We build to that: authorization is refreshed before it lapses, a revocation stops the read cleanly, and every access is logged against the consent that permitted it.

Siirto itself sits inside a live piece of Finnish payments policy. In 2025 the Bank of Finland recorded that responsibility for developing the Finnish Instant Payments Scheme Rulebook moved from the Payments Council to Siirto Brand Oy, after a 2024 working group completed the rulebook around common European standards and an open operating model. We track that because it shapes which standards a forward-looking Siirto integration should align to, and we frame the work as authorized data extraction for interoperability — documented, consented, NDA-covered where a client needs it, never anything that touches authentication it should not.

Engineering realities we plan around

Two things about Siirto change how the build is sequenced, and we handle both as part of the work.

The surface is moving under us

With the standalone app retired and the service inside Nordea Mobile, we anchor the integration on the consented bank feed — the settlement side, which is stable across that move — and treat any client-traffic analysis as version-tracked work against the current Nordea Mobile client. That way the discontinuation of the old binary does not strand your sync.

Per-bank scoping and the 24/7 clock

Siirto legs settle between several Finnish banks, and a consented connection is per institution, so we map and normalise each bank's fields into one schema before your code sees a difference. Because the rail runs around the clock, we design the consumer to run continuously and reconcile by replay rather than assuming a quiet nightly window — the freshness target is set with you, and access to a consenting account or a bank sandbox is arranged during onboarding, on our side, not handed to you as homework.

Working with us

A first Siirto drop — a runnable consumer, its tests, and the docs — is a one-to-two-week piece of work. You can take it two ways. Buy the source outright from $300: we build the integration, hand you the code and documentation, and you pay once it is delivered and you are satisfied. Or call our hosted endpoints and pay per call, with no upfront fee, if you would rather not run the consumer yourself. Either way you tell us the app and what you need from its data; the access, consent onboarding, and compliance paperwork are things we arrange with you. Tell us what you are building and we will scope it.

How this brief was put together

Written from the public record in late May 2026: the Nordea Siirto product pages and the app's store listings for features and the discontinuation timeline; the Bank of Finland release on the instant-payments rulebook moving to Siirto Brand Oy; and Finanssivalvonta's PSD2 framework for the consent and supervision basis. Figures such as the near-million user count are quoted as the sources state them, not asserted independently.

• Nordea — Siirto product page
• Bank of Finland — instant-payments rulebook to Siirto Brand Oy (2025)
• Finanssivalvonta — PSD2 regulatory framework
• Google Play — Siirto - Digital Cash listing

OpenFinance Lab · engineering notes, 31 May 2026.

Interface evidence

Store screenshots, for reference to the surfaces described above.

Where Siirto sits among Nordic payment apps

A unified payments integration usually has to read several of these at once. Neutral notes on the neighbours:

• MobilePay — the dominant Finnish and Danish mobile wallet for in-store and online payments; holds transaction and merchant records alongside Siirto's P2P niche.
• Vipps MobilePay — the merged Norwegian-Danish-Finnish group; carries P2P and merchant payment histories across the three markets under one operator.
• Swish — Sweden's bank-backed real-time P2P app; account-to-account transfers keyed to phone numbers, structurally close to Siirto.
• Trustly — account-to-account payment provider across the Nordics; holds bank-payment records useful to reconcile against app-level transfers.
• Pivo — the OP-backed Finnish wallet discontinued in 2023; relevant as legacy history a migration may still need to read.
• OP-mobile — Osuuspankki's banking app; one of the Finnish banks whose accounts settle Siirto legs, so its statements overlap Siirto activity.
• S-Pankki — another participating Finnish bank; its account feed carries the same Siirto-settled transfers from the holder's side.
• Nordea Mobile — the app Siirto is being absorbed into; the current home of the transfer flows described here.

Questions integrators ask about Siirto

The standalone Siirto app is gone — where does the data actually come from now?

The separate Siirto listing under fi.nordea.mep.p2p was wound down at the end of May 2026 and the transfer flows moved inside Nordea Mobile. That does not remove the data; it relocates the surface. We reach the same payment records through a consented PSD2 account information connection to the user's Finnish bank, where the account-to-account legs settle, rather than against a standalone app binary that no longer ships.

How do you keep a Siirto event stream from missing or double-counting transfers?

Each consumed transfer carries a stable settlement identifier, and we persist the last processed offset. On a restart or backfill we replay from that offset and discard anything already written by its identifier, so a dropped connection or a re-run lands the same ledger either way. Because Siirto settles 24/7, the consumer is built to run continuously and catch up by replay rather than by a nightly window.

Which Finnish banks does a Siirto integration actually touch?

Siirto transfers settle account-to-account between the participating Finnish banks — Nordea, OP, S-Pankki and Aalandsbanken are the ones reported across the sources we read. A consented account-information connection is scoped per bank, so we map the consumer per institution and normalise the differing field names into one schema before your code ever sees them.

Does reaching Siirto data need each user's consent, and how long does it last?

Yes. Under the Finnish Payment Services Act and Fin-FSA supervision, account information is read through the customer's explicit consent and strong customer authentication. Consents are time-bounded and revocable, so we design the sync to refresh authorization before it lapses and to stop cleanly when a user revokes, with every read logged against the consent that authorized it.