Pulling balance and transaction data out of YAP

Behind a YAP login sits a payment account with an Italian IBAN, a virtual Mastercard, and a running movement list, with the available balance capped around €1,500 (per the carteprepagate cost guide). The account is owned by Nexi Payments, the dominant digital-payments operator in Italy, so the data and the route to it both sit inside a regulated payments stack rather than a loose consumer app. That changes how an integration is built: the cleanest authorized path runs through Italy's PSD2 account-information machinery, with a direct consented session as the working alternative.

Why this is a PSD2 account, not just an app

YAP issues an IBAN, holds a balance, and records card and transfer movements. Under PSD2 as transposed in Italy by Decreto legislativo 218/2017, that makes it a payment account a licensed account-information service provider can read on the account holder's instruction. In practice Italian institutions expose this through CBI Globe, the CBI consortium's shared API gateway that standardizes access across more than 400 Italian banks and payment providers and sits under Banca d'Italia supervision. Consent is explicit, scoped to read-only information, time-boxed, and revocable by the user at any point.

One caveat specific to YAP: the IBAN is receive-only. It accepts inbound SEPA credits but does not originate outbound transfers, so an integration here is about reading and reconciling, not initiating payments. We design around that from the start. The consenting account holder must be an Italian resident with a codice fiscale; the minimum age is 12, per the app's own listing — a detail that affects how a consent and document-check flow is scripted.

What data the account actually holds

Authorized routes

1. PSD2 account-information access (AIS)

The licensed path. YAP balance, the limit ceiling, and the movement list are read as a payment account through an AISP consent, brokered in Italy via CBI Globe. Reachable: balances, transactions, account identity. Effort is moderate — most of it is the consent and onboarding handshake, which we arrange with you. Durability is the strongest of the routes because it's a supervised, contractual interface rather than a UI that can shift. This is the route we lead with for anything that has to keep running unattended.

2. Consented protocol analysis of the app session

Where a use case needs fields the AIS surface doesn't expose — granular merchant strings, top-up provenance, the P2P graph — we analyze YAP's own authenticated traffic against a consenting account. We document the login, token issuance and refresh chain, then implement the specific reads. Effort is higher and it needs re-validation when the app front end changes; the upside is access to exactly what the app shows its own user.

3. Native in-app history as a fallback

The app keeps a visible transaction history. For one-off or low-frequency needs, a consented capture of that history is the lightest option and a useful backstop while a durable AIS consent is being set up. It's narrow but quick.

For most YAP work the licensed AIS route carries the production load and protocol analysis fills the gaps it can't reach — we'd commit to the AIS consent for anything that has to survive app updates, and reach for the session-level reads only for the fields it leaves out.

A read, normalized

What a movement sync looks like once normalized — the same shape whether it's fed by an AIS consent or a documented app session:

# YAP movement sync - normalized read
# auth: PSD2 consent token (CBI Globe) OR consented app session token
GET /accounts/{iban}/transactions?from=2026-05-01&limit=100
Authorization: Bearer <consent_access_token>
PSU-Consent-Id: <periodically re-authenticated consent id>

200 OK
{
  "account": {
    "iban": "IT..",                       # receive-only SEPA inbound
    "scheme": "MASTERCARD_PREPAID",
    "balance": {"available": 412.50, "ceiling": 1500.00, "currency": "EUR"}
  },
  "transactions": [
    {"id": "...", "ts": "2026-05-30T19:04:11+02:00",
     "amount": -8.50, "currency": "EUR",
     "type": "CARD_PURCHASE", "merchant": "Bar ...", "channel": "GOOGLE_PAY"},
    {"id": "...", "ts": "2026-05-29T10:00:00+02:00",
     "amount": 50.00, "type": "TOPUP", "source": "P2P_YAP"}
  ]
}
# field names confirmed against the app's movement list during the build;
# balance ceiling (~EUR 1,500) per the carteprepagate cost guide, not a vendor constant.

What lands at the end

Output is built around YAP's real surfaces, not a generic kit:

• An OpenAPI/Swagger spec for the normalized account, balance and movement reads.
• A protocol and auth-flow report — for route 1, the AISP consent and CBI Globe handshake; for route 2, the YAP login, token issuance and refresh chain.
• Runnable source for the key reads in Python or Node.js: balance, movement pagination, top-up and P2P parsing, incoming-credit matching against the IBAN.
• Automated tests, including the consent-refresh path and the €1,500 ceiling edge case.
• Interface documentation plus data-retention and consent-logging guidance fit for Italian/EU handling.

Things we handle in the build

Two YAP specifics we account for up front:

• Receive-only IBAN. Because the account takes inbound SEPA credits but issues no outbound transfers, we build incoming-credit reconciliation and balance/limit tracking — there is no payment-initiation path to model, which simplifies scope and removes a class of error.
• Consent lifetime. PSD2 read consents expire and need periodic strong-customer re-authentication. We fold that re-auth window into the sync schedule so a long-running YAP feed re-validates on time rather than going quiet mid-month.
• Italian identity flow. Onboarding needs a codice fiscale, an Italian phone number and a document check (age 12+). Access is arranged with you during onboarding and the build runs against a consenting Italian account, so the registration and login sequence in the integration match the live app exactly.

We work authorized and documented throughout: consent records and access logs are kept, data is minimized to what the use case needs, and an NDA is in place where the engagement calls for one.

Interface evidence

Screens from the current listing — useful when mapping which fields surface where. Tap to enlarge.

Similar apps in the Italian wallet space

Same-category apps an aggregator or finance product often wants to read alongside YAP. Plain ecosystem context, no ranking:

• Hype — Italian payment account with app and international card; balance, transactions and IBAN behind login.
• Postepay — Poste Italiane prepaid card with a balance held separate from a main account; widely held in Italy.
• Revolut — multi-currency account and card; balances, transactions and FX records per user.
• Satispay — phone-based payment network for shop payments and P2P, tied to a funding source rather than a card number.
• N26 — mobile bank with a Mastercard debit account; statements and transaction history per user.
• Tinaba — send, pool and share money, integrated with Banca Profilo products; expense and savings data.
• Wise — multi-currency balances and a card with detailed transaction and conversion records.
• Nexi Pay — Nexi's own card-management app; card, transaction and statement data, same operator as YAP.

Questions integrators ask about YAP

YAP only receives SEPA transfers and can't send them — does that limit what an integration can read?

No. The receive-only IBAN restricts money movement, not visibility. Balance, the available-limit ceiling, incoming top-ups and the full movement list are all readable; we build read and reconciliation flows rather than payment initiation, since the account does not originate outbound transfers.

Is YAP reached through Italy's PSD2 / CBI Globe layer or through the app itself?

Both are on the table. As a Nexi payment account with an IBAN, YAP balance and transaction data fall under PSD2 account-information access, which in Italy is brokered through the CBI Globe gateway under Banca d'Italia supervision. Where that route does not fit a use case, we work the app's own authenticated session under the account holder's consent. We recommend the AIS path first for anything that needs durable, supervised access.

What identity rules shape a YAP build?

YAP onboarding needs an Italian codice fiscale and an Italian phone number, and the minimum age is 12, per the app's own listing. We run the build against a consenting Italian account so the registration, document check and login sequence in the integration mirror the live flow.

Cost and how to start

Delivery for a YAP build lands in one to two weeks. Source-code delivery starts at $300: you get runnable source for the reads, the OpenAPI spec, tests and interface docs, and you pay after delivery once it works for you. Prefer not to host anything? Call our endpoints on a pay-per-call basis with nothing upfront. Tell us the app and what you need from its data at /contact.html and we will scope it — access, consent and compliance are arranged with you as part of the work.

Sources and review

Checked in June 2026 against YAP's Play Store listing and the it.nexi.yap package, independent Italian cost and feature write-ups, and primary material on Italy's PSD2 / open-banking setup. Balance ceiling, top-up channels and the receive-only IBAN come from the cost guides cited; the regulatory basis from Banca d'Italia and open-banking tracking sources below.

• YAP on Google Play (it.nexi.yap)
• YAP costs, limits and top-up channels (carteprepagate.org)
• How YAP works and its IBAN (Wise)
• Open banking in Italy — CBI Globe, AISPs
• Banca d'Italia — payment institutions FAQ

Compiled by the OpenBanking Studio integration desk · June 2026.