Reaching Lydia and Sumeria account data the authorized way

Lydia Solutions runs as an electronic money institution supervised by the ACPR and the Banque de France, which sets the whole tone of how its data is reached: not by scraping a public site but through consented, regulated account-information access. Behind the wallet sits a real French IBAN, a transaction ledger, peer-to-peer transfers keyed to phone numbers, and the money pots the app is best known for. TechCrunch put the user base at roughly 8 million when the 2024 Sumeria launch was announced. That backend is what an integrator actually wants to query.

The bottom line is straightforward. For a third party that needs a French user's Lydia activity in a system of record, consented account-information access is the durable spine, and it fits because Lydia is itself a regulated payment account holder. Where a use case sits outside a pure read of payment-account data — money-pot internals, card-level detail, the app's own activity feed — we read the authenticated session directly under the user's authorization. Most real projects use both.

What data the app actually holds

Lydia presents several distinct surfaces, and they do not all behave the same way. The table maps each to where it originates and what an integrator typically does with it.

How we reach it

Two or three routes genuinely apply here. They differ in reach, durability and what we set up to run them.

Consented account-information access (AISP)

Because Lydia holds a regulated payment account with an IBAN, its transaction and balance data falls inside the scope of DSP2 account-information services. Working through an AISP authorization, a consenting user grants read access and we pull the normalized account and transaction feed. Reach is the payment-account core; durability is high because the legal basis is explicit and stable; what changes is consent lifecycle, which we handle. Onboarding to an AISP channel is arranged with you during the build.

Protocol analysis of the authenticated session

Money-pot internals, card-level detail and the app's own richly-typed activity feed live above the plain payment-account read. For those we analyze the app's authenticated traffic under the account holder's authorization, document the token and request chain, and rebuild the calls as clean endpoints. Reach is broad; durability depends on the app's front end, which is why we build in a re-validation step. Access is set up with you against a consenting account.

Native export as a backfill

The monthly CSV and PDF statements give a reliable schema and a clean historical backfill. We treat them as a seed and a cross-check, not as the live channel, since a monthly file cannot drive anything real-time.

For most engagements the consented account-information feed carries the day-to-day transaction sync, and session-level protocol analysis fills in the pot and card surfaces it cannot see. We make the specific call once we know which surfaces your use case touches.

What lands in your repository

Each deliverable is tied to a real Lydia surface, not a generic kit:

• An OpenAPI specification covering the account, transaction, money-pot and card endpoints as modeled for your use case.
• A protocol and auth-flow report: the token issuance and refresh chain for the authenticated session, and the AIS consent handshake where that route is used.
• Runnable source for the key calls in Python and Node.js — transaction pull, pot read, statement parse — with retries and error handling.
• A normalized schema that reconciles the CSV statement fields with the live feed, so a transaction looks the same whichever route produced it.
• Automated tests against recorded fixtures, plus interface documentation and data-retention guidance aligned to GDPR.

A worked call

Illustrative only — exact field names and the auth chain are confirmed against a live, consenting account during the build. This sketches the consented transaction pull with a normalized money-pot read alongside it.

# Illustrative — shapes verified during the engagement, not copied from a public spec
POST /oauth/token                      # AIS consent exchange or session refresh
  grant_type=refresh_token
  -> { access_token, expires_in, consent_id }

GET /accounts/{id}/transactions?from=2026-05-01&limit=200
  Authorization: Bearer <access_token>
  X-Consent-Id: <consent_id>
  -> { "transactions": [
        { "id": "...", "booked_at": "2026-05-12",
          "amount": -18.40, "currency": "EUR",
          "type": "p2p_transfer", "counterparty": "+33•••••" } ],
       "next_cursor": "..." }

# money pots are a separate object, modeled on their own
GET /pots/{pot_id}
  -> { "pot_id":"...", "title":"...", "collected": 240.00,
       "currency":"EUR", "contributions":[ {"amount":20.0,"at":"..."} ],
       "withdrawal_state":"open" }

# error handling we wire in: 401 -> refresh once; 429 -> backoff;
# consent expiry surfaces as a typed ConsentExpired, not a silent empty page

Engineering notes we account for

Two things about Lydia specifically shape the build, and we handle both rather than hand them to you:

• The Lydia-to-Sumeria migration. The brand is splitting the current-account experience into Sumeria while the same Lydia Solutions backend issues the IBAN and books movements. We map both front ends and key the integration to the stable backend identifiers, so a user moving to Sumeria does not break the feed.
• Consent and session lifetimes. AIS consent expires and has to be re-confirmed; an authenticated session token has its own shorter window. We design the sync around both clocks so it refreshes ahead of expiry instead of failing quietly, and we wire a re-validation pass into maintenance for when the app's front end shifts.
• Money pots are not transactions. A pot has contributors and a withdrawal state a transfer never carries, so we model it as its own object instead of flattening it into the activity stream where downstream logic would misread it.

Access to a sandbox or a consenting account is arranged with you during onboarding; it is part of how the project runs, not something you clear first. We work authorized, log what we touch, minimize the data we hold, and sign an NDA where the work calls for one.

Where this gets used

• A French accounting tool pulling a freelancer's Lydia transactions straight into its books each morning.
• An events platform reading money-pot contributions to reconcile group collections against ticket lists.
• A personal-finance app folding Sumeria IBAN movements into a single multi-account balance view.
• An expense product that turns Lydia card authorizations into a typed spend feed.

How this was put together

Checked in June 2026 against Lydia and Sumeria support documentation for the statement and IBAN behaviour, the ACPR's open-banking material for the DSP2 footing, and contemporaneous reporting on the Sumeria launch and user base. Figures such as the ~8 million users and the money-pot volume are cited as the sources state them, not independently audited.

• TechCrunch — Lydia launches Sumeria (user base, 2024)
• Lydia support — transaction history and statements
• Sumeria manual — the Lydia IBAN
• ACPR — open banking in France (DSP2)

Mapped by the OpenBanking Studio integration desk · 5 June 2026.

Adjacent apps in the same space

These come up alongside Lydia for anyone building a unified view of French and European wallets; named for ecosystem context only.

• Revolut — multi-currency account with cards and transfers; broad transaction and FX history.
• N26 — German mobile bank with a full current account and categorized transactions.
• Wise — multi-currency balances and international transfers with detailed movement records.
• Bunq — Dutch bank with sub-accounts and a transaction API surface.
• Monese — wallet-style account holding balances and transfer history.
• Wero — the bank-backed wallet that replaced Paylib for French P2P payments.
• Lyf Pay — friend transfers, shared expenses and in-store payment records.
• Qonto — business accounts with rich invoice and transaction data.
• Bankin' — an aggregator itself, pulling many French accounts into one feed.

Interface evidence

Store screenshots, useful for reading the actual surfaces the data lives behind. Tap to enlarge.

Questions integrators ask

Does Lydia's shift toward Sumeria change which account data we can reach?

Not in substance. The same Lydia Solutions backend issues the IBAN, books transfers and holds the activity feed; the Sumeria front end mostly renames and extends the current-account surface. We map both shells during the build so the integration keeps working as users migrate.

Can the in-app CSV and PDF statements be turned into a live feed?

Yes. Lydia exposes monthly statements in CSV and PDF per its support docs, which is a clean schema reference, but a monthly file is not a feed. We pair that schema with consented account-information polling or session-level protocol analysis so transactions arrive continuously rather than once a month.

Which French rules govern consented access to Lydia transaction data?

Lydia Solutions is an electronic money institution supervised by the ACPR, so account-information access runs under PSD2 (DSP2 in France) through an AISP authorization, with GDPR governing the personal data. Consent scope, expiry and revocation are wired in explicitly.

Are money-pot contributions reachable the same way as personal transfers?

They sit on a separate surface. A money pot (cagnotte) carries its own contributor list, per-contribution amounts and a withdrawal state that a personal transfer does not have, so we model pots as a distinct object with its own normalized schema rather than folding them into the transaction stream.

The runnable source for your Lydia surfaces lands inside a one-to-two-week cycle. You can take that build for a fixed fee from $300, billed only after delivery once you have what you asked for — or skip the build fee entirely and call our hosted endpoints, paying only per call. Tell us the app — Lydia — and what you need out of it, and we set up the rest. Start at /contact.html.