Building an authorized integration for AUB Mobile Banking

Asia United Bank's mobile front end carries enrolled AUB Preferred deposit accounts, InstaPay and PESONet outgoing transfers, accredited bills payment, PDC check management, credit-card servicing, FX buy/sell, CASHelp salary-loan applications and auto/big-bike loan flows — server-side state behind a per-client session that an aggregator, an accounting tool or a Philippine fintech wallet routinely wants to read on behalf of a consenting AUB client. The route into that state is authorized integration: customer-permissioned data sharing under BSP Circular 1122 where it fits, and direct protocol analysis of the AUB Mobile Banking traffic under the client's authorization where speed matters.

Reachable data domains for an AUB client

The rows below follow the way the AUB Mobile Banking app itself surfaces things to a logged-in client. They are the units a consent line should be written against, and the units the delivered client exposes.

Route options that actually apply here

1 · Customer-permissioned data sharing under BSP Circular 1122

The Bangko Sentral ng Pilipinas issued Circular 1122 on 17 June 2021, formalizing the Philippine Open Finance Framework; the Open Finance PH Pilot launched with IFC/World Bank support in 2023. BSP-supervised institutions with a sufficient composite supervisory rating are eligible participants. The build sits a third-party-provider client on this consent path: the AUB client authorizes named scopes (accounts, transactions, credit card), the consent record carries an expiry and revocation hook, and the data minimization aligns with what the line actually grants. Heavier to onboard, durable once running.

2 · Authorized interface integration / protocol analysis

Under the consenting AUB client's explicit authorization, we analyze the AUB Mobile Banking app's traffic — the OAuth/token chain it uses, the TLS-pinned channel, the server-side endpoints behind the account list, statement query, InstaPay/PESONet submission and credit-card statement read — and implement a runnable client around those surfaces. This is the route most engagements actually start on, because it produces a working pull within days while a Circular-1122 consent path is being wired through.

3 · User-consented credential / session access

For an individual AUB client who wants to give a personal tool access to their own data, the build runs against the user's session with an explicit revocation switch and audit log. Narrower than the institutional route, but the right shape for personal-finance and household-budget tools.

4 · Native export fallback

AUB Preferred Online Banking and the mobile app expose statement PDFs and on-screen exports. Lossy for transaction-level reconciliation but useful as a regression baseline against the live client.

The recommendation we make in almost every AUB engagement is to start on route 2 so a working client lands inside the 1–2 week cycle, and to migrate the same surfaces onto route 1 once the consent path is in place — the schemas the build emits are designed to keep the consumer code unchanged across that move.

A concrete look at the auth and statement flow

The pseudo-code below sketches the shape the delivered Python and Node.js clients take against AUB. Exact field names, header layout and the token-refresh sequence are confirmed during the build against a consenting test account or a sponsor sandbox.

# Illustrative — concrete schemas, headers and token chain are confirmed during the build
import requests
from datetime import date

BASE = "https://api.openbankingstudio.com/aub/v1"

def open_session(consent_id: str) -> dict:
    # Consent record carries scope + expiry under Circular 1122 framing,
    # or the client's direct authorization on the protocol-analysis route.
    r = requests.post(f"{BASE}/sessions", json={
        "consent_id": consent_id,
        "scope": ["accounts.read", "txns.read", "card.read", "pdc.read"],
    })
    r.raise_for_status()
    return r.json()  # {session_id, expires_at, scopes[]}

def list_enrolled_accounts(session_id: str) -> list:
    r = requests.get(f"{BASE}/accounts",
        headers={"X-Session-Id": session_id})
    return r.json()["accounts"]  # account_id, type, currency, masked_no, balance

def get_statement(session_id: str, account_id: str, since: date) -> dict:
    r = requests.get(f"{BASE}/accounts/{account_id}/statement",
        headers={"X-Session-Id": session_id},
        params={"from": since.isoformat()})
    return r.json()  # {opening_bal, closing_bal, transactions[]: {amount, ref, channel}}

def pesonet_status(session_id: str, transfer_ref: str) -> str:
    # PESONet legs are pending until the relevant 10:00 / 16:00 cut-off,
    # so callers should treat "pending" as expected, not as an error.
    r = requests.get(f"{BASE}/transfers/pesonet/{transfer_ref}",
        headers={"X-Session-Id": session_id})
    return r.json()["status"]  # submitted | pending | settled | rejected

What you receive at the end of the build

• An OpenAPI / Swagger specification covering the AUB surfaces in scope — at minimum accounts list, statement retrieval, InstaPay status, PESONet status, credit-card statement read, PDC item list, CASHelp loan-application status.
• A protocol and auth-flow report: the OAuth/token chain, refresh behavior, TLS-pinning notes, and the request shape per endpoint.
• Runnable client source in Python and Node.js, structured so the same call surface works whether traffic goes through route 1 or route 2.
• An automated test pass — recorded-fixture regression plus a live consent-flow check against a sponsor sandbox or a consenting AUB account.
• Interface documentation written for the engineer who has to maintain this in six months, not for marketing.
• A short data-retention and consent-record note grounded in the DPA's lawful-basis requirements and BSP's Circular 1122 expectations on customer-permissioned data.

Open Finance PH, bank secrecy and the Data Privacy Act

Three Philippine instruments shape any AUB build. BSP Circular 1122 is the operating framework — customer ownership of data, third-party-provider participation, and scope-based consent. The Data Privacy Act of 2012 (RA 10173) sets the lawful-basis and data-subject-rights floor, with the National Privacy Commission as the regulator; AUB's own published privacy posture commits to the DPA explicitly. The Anti-Money Laundering Act and the Secrecy of Bank Deposits laws still apply on top, so the build redacts deposit identifiers from ordinary application logs and routes only the scope the consent line actually carries. Consent records are stored with the scope, granted-at, expires-at and revocation entries the regulator expects.

Engineering notes the build accounts for

Three things shape almost every AUB engagement, and the integration is designed around them up front so they do not surface as surprises later.

• Per-product enrollment is not a single consent surface. Enrolling an "AUB Preferred Account" in mobile banking is distinct from enrolling a credit-card portfolio or the HelloMoney wallet. We model each as its own session scope, so a consent line that grants account-statement reads does not silently broaden to card transactions.
• PESONet and InstaPay are timed differently. InstaPay credits in real time per AUB's published fund-transfer note, while PESONet posts against AUB's two same-day cut-offs (10:00 AM and 4:00 PM). The reconciliation logic treats PESONet legs as pending until the relevant window passes, so a calling ledger does not flag the gap as a failed transfer.
• The portal front end changes; the wire shape is more stable. Where the build runs on the protocol-analysis route, ordinary maintenance includes a scheduled regression check against the live AUB mobile traffic so a portal refresh shows up the same week rather than as a silent drift in the schema. Access and any sponsor sandbox are arranged with the client during onboarding — that work is part of the engagement, not a precondition the client has to clear first.

Sample integrations we have shaped this brief around

• A Philippine accounting SaaS reading enrolled AUB deposit accounts and PESONet payroll legs to keep an SMB's books reconciled day-by-day.
• A multi-bank wallet aggregator surfacing AUB balances and the latest 90 days of transactions alongside its other Philippine bank tiles.
• A salary-advance lender reading CASHelp application status and the borrower's recent deposit history with explicit, narrowly-scoped consent.
• A treasury tool pulling AUB credit-card statements and PDC items into a single cash-position view for a mid-sized importer.

Philippine banking apps with comparable integration needs

These appear on most "apps like AUB" or "AUB alternatives" lists; they sit on the same Open Finance PH perimeter and the same DPA floor, so a unified integration design across several of them is the common pattern.

• BPI Mobile — Bank of the Philippine Islands' app, deep authenticated portal with bills payment to several hundred merchants.
• BDO Digital Banking — the largest Philippine bank by assets, broad retail and SME footprint.
• Metrobank Mobile — full retail banking with built-in loan calculators and rate checking.
• UnionBank Online — early-mover digital bank with full account-opening from the app.
• PNB Mobile Banking — Philippine National Bank's retail app, strong overseas-Filipino remittance surface.
• RCBC Pulz — Rizal Commercial Banking Corporation's modernized retail app.
• Landbank Mobile Banking — government-owned bank, large deposit-account base.
• Security Bank Online — retail and credit-card focused, similar PDC and card-servicing surfaces.
• Maya — digital bank and wallet, often co-held with a universal-bank account.
• HelloMoney by AUB — AUB's own sister eWallet on a different package and consent surface.

Provenance

The mapping above was built from the AUB Mobile Banking Play Store listing and the AUB app description, AUB's own InstaPay and PESONet product pages, AUB's published privacy policy and its DPA commitment, and the BSP Circular 1122 PDF and the BSP Open Finance PH landing page. Primary sources opened:

• BSP Circular No. 1122 (Open Finance Framework, June 2021)
• Bangko Sentral ng Pilipinas — Open Finance PH
• AUB — InstaPay product page
• AUB — PESONet product page
• AUB — Privacy Policy (DPA-aligned)

Mapped by the OpenBanking Studio integration desk, May 2026.

Questions an AUB integrator usually asks

Which AUB surfaces are reachable through a consented integration?

Enrolled AUB Preferred deposit accounts (balances and statements), outgoing InstaPay and PESONet transfers with their status, accredited bills-payment records, AUB credit-card statements and rewards, PDC (post-dated check) items, FX buy/sell history, and CASHelp salary-loan and auto/big-bike loan application status. All of it sits behind a per-client mobile session that we drive on the basis of the AUB client's authorization.

How does BSP Circular 1122 shape an AUB integration?

Circular 1122 is the Bangko Sentral ng Pilipinas Open Finance Framework issued in June 2021; it makes customer-permissioned data sharing between BSP-supervised institutions and third-party providers the formal route. AUB is a BSP-supervised universal bank, so the consent line, data-minimization scope and revocation behavior the build implements follow the Circular and AUB's own DPA-aligned privacy posture.

Will the integration handle the InstaPay vs PESONet timing difference correctly?

Yes. InstaPay credits in real time per AUB's published fund-transfer note, while PESONet posts against the two same-day cut-offs (10:00 AM and 4:00 PM per AUB's PESONet page). The reconciliation logic we deliver treats PESONet legs as pending until the relevant settlement window passes, so downstream ledgers do not flag the gap as a failed transfer.

Does the same build cover HelloMoney by AUB or only the main mobile-banking app?

By default we scope to the AUB Mobile Banking app (package com.aub.mobilebanking per its Play Store listing). HelloMoney by AUB is a sister eWallet on a different package and a different consent surface; we can include it in the same engagement, but it is treated as a second target with its own session model and its own consent line.

If a build along these lines is what you need, the engagement is plain. Source-code delivery starts from $300 — runnable client, OpenAPI spec, protocol report, tests and interface documentation — paid after delivery once you are satisfied, with a 1–2 week cycle from kickoff. The pay-per-call hosted alternative skips that fixed fee entirely: you call our endpoints against AUB, and you pay only for the calls you make. Send the app name and what you want pulled out of it to /contact.html and we will scope the rest with you.