Building an InstaPay-aware feed against AUB Mobile Banking

Asia United Bank's mobile app carries the five things a Philippine integrator usually wants out of a bank in one place: balances, transaction history, outgoing InstaPay and PESONet, post-dated-check management, and credit-card statements. The rest of this page sets out the route into each of those, what an OpenFinance Lab build for AUB actually ships, and the BSP and privacy frame the work runs under.

Bottom line: AUB is a buildable target. The data the app shows the user is reachable through a mix of customer-authorized interface integration and the BSP's emerging Open Finance pattern. In practice we lead with route 2 below — authorized interface integration with the customer's consent — and let PESONet and PDC reads ride the same session.

Routes into AUB's data

Four routes apply to AUB. The first is the regulated path: the BSP Open Finance Framework, set out in Circular 1122, sketches a consent-driven model in which a BSP-supervised institution exposes customer-authorized reads to a third party. The framework is live but pilot-led, and the published phase is the Open Finance for PERA pilot run with G-Xchange (GCash), UnionBank, PNB, and RCBC. AUB is not named in the published pilot participant list, so an integration today rides on customer-authorized access rather than a regulator-issued AUB endpoint catalogue.

The second route — and the one we lead with — is authorized interface integration. The customer of AUB authorizes the work in writing, we map the AUB mobile-banking session model (a security-token-driven flow that AUB itself describes in-app), and we wrap the per-account reads behind a small SDK. This is how most Philippine bank integrations get built outside the PERA pilot, and it produces a feed that updates as fast as the user's own app would.

The third route is native export. AUB's app exposes statement and transaction views the customer can request and forward; for a small, low-volume use case this is sometimes enough. For anything event-driven it is not.

The fourth route is PESONet/InstaPay direct, where the destination already has its own rail membership. That route is parallel rather than alternative: it covers outgoing movement, not the AUB-side history a downstream service needs to see.

Data domains the AUB app surfaces

What ships with the build

An OpenFinance Lab build for AUB leads with runnable code, not paper. The deliverable set:

• Python (3.10+) and Node.js (18+) SDKs — session handling with automatic mobile-token re-auth, balance and history fetch, InstaPay and PESONet send with idempotency keys, PDC management, credit-card statement pull. Source you can run on day one.
• Webhook handlers for credit-posting and PDC status changes, with replay-safe ingest and a worked example of dedup against a Postgres journal.
• An automated test suite — fixtures captured during the build (with credentials scrubbed), pytest and Jest cases, contract tests against a recorded session.
• Idempotency design for the two rails (real-time InstaPay vs end-of-day PESONet) so a unified ledger view is consistent across the cutover.
• OpenAPI / Swagger spec for the wrapped surface, so your platform team has a stable contract to code against.
• Protocol and auth-flow report — the AUB security-token chain, the in-app re-auth trigger, error envelopes, and the retry budget we settled on.
• Compliance and data-retention guidance — consent text, NPC-aligned record-keeping, what to log and what not to log.

If the engagement is pay-per-call instead of source delivery, the same SDK calls the hosted endpoints; you do not see the lower-level mechanics, you only see the normalized response.

An InstaPay call against AUB

This is illustrative — exact field names are confirmed during the build against the live session — but it shows the shape an integrator sees once the AUB session is in hand:

# Python SDK — outgoing InstaPay against AUB Mobile Banking
from openfinlab.aub import AUBClient, InstaPayRequest

cli = AUBClient.resume(session_token=token_store.get("aub:user:42"))

# 1) Balance check before queueing a real-time transfer
acct = cli.accounts.preferred()[0]
print(acct.available_balance, acct.currency)  # e.g. 27840.55 PHP

# 2) Build the InstaPay request (BSP-capped per transaction)
req = InstaPayRequest(
    source_account=acct.id,
    destination_bank="BPI",
    destination_account="0123456789",
    destination_name="Juan Dela Cruz",
    amount="2500.00",
    currency="PHP",
    remarks="invoice-1042",
    idempotency_key="ipay-2026-05-27-1042",
)

# 3) Submit — auto re-auth if the mobile-token has rolled
res = cli.instapay.send(req)
assert res.rail == "InstaPay" and res.status in ("ACCEPTED","POSTED")

# 4) Webhook receives the final POSTED event (or REJECTED with reason)
#    POST /webhooks/aub  -> handler dedups on res.transaction_id

The corresponding PESONet call differs in only two places: the rail tag, and the expected status timeline (which trails the cut-off batch). The SDK exposes both so a downstream ledger does not have to know about the rail it is reading.

Consent and the BSP / NPC frame

AUB sits inside the Philippine regulatory perimeter. Three rules anchor the build:

• BSP Circular 1122 (2021) — the Open Finance Framework that sets the consent-driven model, governed by the Open Finance Oversight Committee. The framework is the direction of travel for AUB and every other BSP-supervised institution. The published live testbed is the Open Finance for PERA pilot, which AUB is not part of as of the pilot participants list we cite below.
• BSP NRPS rules — InstaPay and PESONet sit inside the National Retail Payment System; per-transaction caps, posting cadence and clearing-cycle rules apply to anything that touches those rails.
• Data Privacy Act of 2012 (RA 10173) — the National Privacy Commission enforces consent, purpose-limitation, and the data-sharing-agreement rule for commercial use. Consent has to be freely given, specific, informed, and recorded in writing or electronically.

The build carries the customer's authorization as a first-class artifact: the consent text, the scope of reads, the expiry, and the revocation channel are all in the deliverable, not bolted on later. Where the project sits with a corporate customer of AUB, we sign an NDA covering the credentials and the captured session evidence.

Things we account for during the AUB build

• Mobile-token session lifecycle. AUB's app authenticates with a security-token chain that re-issues on a schedule the user sees as occasional in-app re-auth. A long-running ingestion job has to know about that schedule and gracefully prompt the consenting user, not silently lock the account. We map the lifecycle during the first build week and the SDK handles it.
• PDC checks are unusual. Most aggregator schemas don't model PDC status transitions (pending → redeposited → pulled-out → cleared / returned). We extend the normalized schema with a pdc_status enum and a pdc_event log so a downstream finance system does not collapse a post-dated cheque into a generic pending transaction.
• Rail cadence asymmetry. InstaPay posts in seconds; PESONet posts in an end-of-business-day batch. The sync design uses different windows for the two so a unified ledger view does not flap when an outgoing PESONet sits in clearing across the cut-off. The webhook for credit-posting is the source of truth, not the polled history.
• Cross-border QR. If the integration scope includes the AUB-Singapore QR corridor (Liquid Group), the FX leg has its own consent and AML scope; we keep that out of the main reconciliation pipeline and route it to its own queue.
• Bank-secrecy reconciliation. The DPA and bank-secrecy rules overlap with AMLA obligations on the bank side. We design the consent text so the customer's authorization to share their own data does not collide with the bank's own confidentiality posture; the project is set up between the customer and the studio, with access arranged during the first onboarding meeting.

Scenarios we have seen for AUB

1. Payroll co-pilot for an SME. Read the AUB operating-account balance every morning, pre-stage the PESONet batch from the HRIS file, send at the cut-off, and reconcile the webhook events back to the journal.
2. Marketplace payouts. Send small InstaPay disbursements to seller accounts at any bank, idempotent per order, retry on REJECTED with a known reason, and surface the rail receipt to the seller.
3. Working-capital dashboard. Combine current balances, PDC queue (with the extended status), and credit-card receivables into a single position view refreshed on a 5-minute heartbeat for InstaPay events and an end-of-day pass for PESONet.

Sync reliability and freshness

The reliability budget we ship with is honest: real-time freshness on the InstaPay side, end-of-day on PESONet, and a recovery procedure when an in-app re-auth interrupts the session. The SDK carries a circuit-breaker per surface so a failure on PDC reads does not knock balance reads offline. The audit log carries the request id and the consent scope used for each call, which is what an NPC review tends to ask for.

Engagement and pricing

The first runnable drop is one to two weeks from kick-off — the AUB session model and the two rails fit inside that window. Source-code delivery from $300 gets you runnable Python and Node.js source, the OpenAPI spec, the auth-flow report, the test suite and the interface documentation, paid after delivery once you are satisfied. Pay-per-call hosted API is the alternative — you call our endpoints, you pay per call, there is no upfront fee. Access, sandbox arrangement and the consent paperwork are part of the engagement and we set them up with you. If you have a target use case in mind, tell us about it on the contact page; the studio replies inside a working day.

How this brief was put together

The technical content above is drawn from AUB's own app description and Play Store / App Store listings, BSP's published Open Finance materials, and public reporting on AUB's payment work. Specific sources cited in this brief: the BSP Open Finance page, the NPC Data Privacy Act of 2012 reference, the AUB Mobile Banking Play Store listing, and the Finextra report on the AUB-Singapore QR corridor with Liquid Group. Internal note: the BSP PERA pilot participants we list are taken from the BusinessWorld and FintechNews Philippines reporting on the pilot launch; AUB is not in that participant list as published. Reviewed May 2026 by the OpenFinance Lab integration desk.

Other Philippine bank and wallet apps integrators usually evaluate alongside AUB

Buyers comparing AUB usually look at the same handful of Philippine banks and wallets. Each holds its own version of the same customer data; a unified integration usually covers several of them at once.

• BDO (Banco de Oro) — the largest universal bank by assets; carries deep retail and SME data behind a similar token-based mobile session.
• BPI (Bank of the Philippine Islands) — one of the oldest local banks; mobile app holds deposit, credit, and investment data inside a single account.
• Metrobank — universal bank with a similar InstaPay/PESONet footprint and an active mobile-app refresh cycle.
• UnionBank of the Philippines — early Open Finance participant; named in the BSP PERA pilot.
• PNB (Philippine National Bank) — universal bank, in the BSP PERA pilot.
• RCBC — universal bank, in the BSP PERA pilot, with active digital-onboarding.
• Security Bank — private universal bank with a similar mobile feature set.
• China Bank PH — universal bank, strong SME footprint.
• Landbank — government-owned, in the broader pilot, sees high payroll-and-disbursement volume.
• GCash — operated by G-Xchange (Mynt); the largest Philippine e-wallet, also in the PERA pilot.
• Maya — digital bank and wallet; carries retail-payments and credit data.

Questions integrators ask about AUB

Can you ingest AUB InstaPay events in near real-time, or only end-of-day?

InstaPay is a real-time clearing rail, so the AUB-side surface that records an outgoing or incoming InstaPay event updates within seconds of posting. We design the sync to poll that surface on a short interval for credits and to capture outgoing transfers from the call we make on the user's behalf. PESONet, which posts in batches at end of business day, gets its own slower sync window so the unified ledger does not flap.

How do you model AUB's PDC checks, which most aggregators don't cover?

We extend the normalized schema with an explicit pdc_status enum (pending, redeposited, pulled_out, cleared, returned) and a pdc_event log so downstream reconciliation does not collapse a post-dated check into a generic pending transaction. The mapping is documented with the interface notes so your finance team can wire it into reporting without a separate guess-pass.

What does the Python and Node.js SDK actually do for an AUB build?

The Python and Node.js clients wrap session handling (mobile-token lifecycle, automatic re-auth on expiry), the balance and transaction-history calls, an InstaPay send with idempotency keys, a PESONet send for higher-value batched transfers, and the PDC management surface. Webhook handlers ship for credit posting and PDC status changes so your service does not have to poll for every event.

Which BSP rules apply when an integrator reaches into AUB?

BSP Circular 1122 (2021) sets the Open Finance Framework and the consent-driven model the BSP wants the industry to converge on; the BSP-led Open Finance for PERA pilot is the live testbed. AUB is a BSP-supervised universal bank, so any third-party access uses the customer's authorization and respects the Data Privacy Act of 2012, enforced by the National Privacy Commission. We carry the consent record, the data-minimization scope, and the retention window in the build.