Pulling balances, cards and transfers out of UnionBank Online

UnionBank of the Philippines was reported by Philippine fintech press as the first bank to go live on the Bangko Sentral ng Pilipinas Open Finance for PERA pilot. That detail matters more than any feature list: it says the consent rails around this bank are operating, not hypothetical. For an integrator the practical question is narrower. The UnionBank Online app sits over a stack of deposit products, Visa card programs, loan accounts and four payment rails, and the job is to get that per-customer data out cleanly, under authorization, and keep it flowing. This brief lays out what the app holds, the routes that actually reach it, and the source we hand back.

The bottom line: breadth lives in the authenticated app and web portal, and the regulated consent path is genuinely emerging here rather than absent. We build against the interface for full coverage and fold in the Open Finance consent route where UnionBank's participant connection is live for the use case. That keeps the integration honest about what is settled today and ready for what the pilot turns on next.

The Philippine consent and privacy picture

BSP Circular No. 1122, the Open Finance Framework, was issued in 2021 and frames data sharing as consent-driven: the customer owns the transaction data and grants access. Governance sits with an industry-led Open Finance Oversight Committee, and the Open Finance PH pilot — supported by the IFC — has been running in tranches, with account aggregation and reusable KYC among the tested use cases. UnionBank is a flagship participant; Philippine fintech press reports it as first to go live on the Open Finance for PERA pilot and credits it with a long open-banking track record. The honest read for an integrator: the scheme is live and phased, so the regulated route's coverage depends on which connections are exposed for your case at the time, not on whether the framework exists.

Privacy sits under the Data Privacy Act of 2012 and the National Privacy Commission, which recognizes only express, specific, informed consent. Banking data also carries the Secrecy of Bank Deposits Act, the Foreign Currency Deposit Act and the Credit Information System Act on top of general privacy law. We operate inside that: authorized or user-consented access only, consent and access logs kept, data minimized to the fields a use case needs, NDAs where the engagement calls for one. Compliance here is how the desk works, not a form we hand you to clear first.

What the app holds, account by account

These are the app's own surfaces, not a generic banking checklist. The split that drives the integration design is rails versus records: balances and statements are stable to read, while InstaPay, PESONet and PDDTS each settle on their own clock and need separate status handling.

Routes in, and the one we would run

1 — Authorized interface integration

The widest coverage. We work the authenticated traffic of the app and the web portal at online.unionbankph.com under the customer's authorization, treating it as reverse engineering for interoperability. Everything in the table above is reachable this way: balances across products, card statements, transfer history with rail and fee, loan repayment, scheduled instructions. Effort is medium to high because of the OTP and biometric step-up; durability is medium, since a portal front-end change means we re-run a validation sweep and patch. Access — a consenting account or a sponsor sandbox — is set up with you as the build starts.

2 — BSP Open Finance consent

The regulated path, under Circular 1122 and the Open Finance PH pilot. Where UnionBank's participant connection is live for your case, account and balance information flows with explicit customer consent, consent scope and expiry managed to the framework. Durability is high where it is live; coverage tracks pilot phase. We handle third-party onboarding and consent setup with you rather than handing it over as a checklist.

3 — User-consented export fallback

Where a customer pulls their own statements or records from the app or portal, we use that as a supplement for backfill and reconciliation — narrower and less timely than route 1, useful as a cross-check.

For this bank we build on route 1 first. It covers every surface a UnionBank integrator asks for and does not wait on pilot timing, while route 2 gets layered on the moment a live participant connection reaches the use case. Route 3 stays as a backstop. The integration is designed so the consent path can take over reads later without you re-scoping the project.

What you get at the end of the build

Concrete artifacts, tied to UnionBank Online's real surfaces:

• An OpenAPI/Swagger specification covering balances, card statements, transfer history by rail, loan repayment and scheduled instructions.
• A protocol and auth-flow report: the login, OTP and biometric step-up, device binding and token-refresh chain as it behaves on this app and the online.unionbankph.com portal.
• Runnable source for the key endpoints in Python and Node.js — balance read, statement pull, transfer-history fetch with rail normalization.
• Automated tests, including the InstaPay vs PESONet vs PDDTS status cases and the multi-product enumeration case.
• Interface documentation and compliance notes: consent records, access logging, retention guidance under the Data Privacy Act and the bank-secrecy statutes.

A statement-and-balance pull, in pseudo-code

Illustrative of the route-1 shape, with field names confirmed during a build, not a generic stub:

POST /auth/session
  body: { username, device_id, channel: "mobile" }
  -> 200 { session_id, step_up: "OTP_REQUIRED" }

POST /auth/step-up
  body: { session_id, otp }            # biometric path returns a signed device assertion instead
  -> 200 { access_token, refresh_token, expires_in: 900 }

GET /accounts                          # enumerate every product under one login
  auth: Bearer access_token
  -> 200 [ { account_id, product: "SAVINGS_PLUS", currency: "PHP",
             balance_available, balance_current } , ... ]

GET /accounts/{account_id}/statement?from=2026-04-01&to=2026-04-30
  -> 200 { period, lines: [ { posted_at, description, amount,
             rail: "INSTAPAY|PESONET|PDDTS|INTERNAL", fee, status } ] }

on 401  -> refresh with refresh_token; if refresh rejected, re-run step-up
on 428  -> step-up re-challenge mid-session; pause sync, re-auth, resume
on 429  -> respect Retry-After; backoff is per-session, not global

The rail tag and the per-line status are the parts that earn their keep. Without them a pending PESONet credit reads like settled cash.

Things this build has to get right

Four judgments specific to UnionBank Online that the desk accounts for:

• Step-up survival. Secured access runs on OTP and biometrics with device binding. We model the step-up and re-challenge points so a long sync does not die mid-run, and we shape token refresh around the session re-auth rather than against it.
• One login, many products. A customer can hold Personal Savings, Savings+, GetGo, a Lazada account and PlayEveryday at once. We enumerate products per login and key data per account so multi-product holders are not flattened to a single balance.
• Rail semantics. InstaPay, PESONet and PDDTS clear on different timelines with different fees; intra-UnionBank moves in real time. We normalize status and fee per rail so downstream systems compare like with like.
• Pilot-phase degradation. Open Finance PH runs in tranches, so we design the consent route to fall back to the authorized interface when a participant connection is not yet live for a use case — coverage does not hinge on pilot timing.

Where teams point this integration

• A personal-finance app aggregating a user's UnionBank balances and card spend next to other Philippine banks for one net-worth view.
• An SME accounting tool auto-matching InstaPay and PESONet receipts against invoices, with rail-aware settlement timing.
• A lender pulling consented balance plus loan-repayment history for an affordability decision.
• A disbursement platform tracking payout status across rails so a queued PESONet batch is not retried as failed.

The wider Philippine money-app cluster

Same-category apps an aggregator usually has to sit alongside; ecosystem context, not ranking:

• Maya Bank — digital bank tied to the Maya wallet, holding savings, credit and loan records.
• Tonik — BSP-licensed neobank with deposits, loans and credit-building products.
• GoTyme Bank — Gokongwei–Tyme venture pairing app accounts with kiosk onboarding.
• UNO Digital Bank — credit-led digital bank with savings and lending data.
• SeaBank Philippines — Sea Limited's banking arm, deposit and transfer activity.
• CIMB Bank Philippines — mobile-first bank that also powers the GSave account inside GCash.
• GCash — e-money wallet holding balances, bills and transfer history for a very large user base.
• UnionDigital Bank — UnionBank's separate digital bank, time deposits and savings.
• BPI — large traditional bank with a digital channel over accounts, cards and loans.
• BDO — major bank whose app exposes deposit, card and payment records.

Screens we mapped against

Store screenshots used while mapping flows; tap to enlarge.

How this brief was put together

Built in May 2026 from the app's own Google Play description and feature copy, the BSP Open Finance materials, Philippine fintech reporting on UnionBank's pilot participation, and the National Privacy Commission's Data Privacy Act pages. Primary sources consulted:

• BSP Circular No. 1122 — Open Finance Framework (PDF)
• BSP — Open Finance PH
• Fintech News PH — UnionBank in the Open Finance for PERA pilot
• National Privacy Commission — Data Privacy Act of 2012

Mapping reviewed 2026-05-16 by the OpenBanking Studio integration desk.

Questions integrators ask about UnionBank Online

Does the Philippine Open Finance pilot let you pull UnionBank data through a consent flow today?

The framework is real: BSP Circular 1122 (2021) set up consent-driven sharing and the Open Finance PH pilot has been running in phases, with UnionBank reported as the first bank to go live on the Open Finance for PERA pilot. What is actually reachable through that consent route depends on which participant connections are live for your use case at the time. Where a connection is not yet exposed, the authorized-interface route reaches the same balances, statements and transfer records, and we design the integration so it shifts between the two without you re-scoping.

Can you tell InstaPay, PESONet and PDDTS transfers apart in the data you return?

Yes. These rails clear on different timelines and carry different fee rules, so we tag every transfer with its channel, a normalized status, the fee charged and the value timestamp. A pending PESONet credit is never reported as if it were a settled InstaPay transfer.

Our users hold several UnionBank products at once — PlayEveryday, Savings+, GetGo. Does that break the pull?

No. One login can sit over Personal Savings, Savings+, GetGo, the Lazada account and PlayEveryday. We enumerate every product under the login and key the data per account, so a customer with four products is not collapsed into one balance figure.

We need consented balance and loan-repayment history for affordability checks — how soon can that be live for UnionBank?

Scoped to just those two surfaces, one to two weeks. The access and the consenting test account are arranged with you while the build runs; you give us the app name and the data you need, and the compliance side is handled inside the engagement.

The commercial side stays plain. We deliver the runnable source plus its documentation for a fee starting at $300, billed only after delivery once the integration checks out on your side; or you run nothing yourself and call our hosted endpoints, paying per call with no upfront cost. The cycle is one to two weeks either way, and you start by giving us the app name and what you want from its data. Talk to us at /contact.html.