Reaching FE ONLINE 2.0's loan, card and Übank account data

FE ONLINE 2.0 pushes every cash-loan disbursement into a Übank digital-bank account, and that account — balance, free inter-bank transfers, the repayment that flows back to FE Credit — is the surface most integrators ask us to reach. The loan itself sits next to it: a limit between 10 and 70 million VND, a 12-to-36-month term, an instalment schedule the app keeps for the borrower (figures as the app's own listing describes them). Reaching all of it means working through one authenticated session, not three.

The honest bottom line: this is a single-borrower portal with real server-side state, and the cleanest route is to drive its own authenticated session against a consenting account, normalize what comes back, and hand you a feed. Where Vietnam's new Open API consent channel is live for the bank leg, we use it. Below is the data, the route, and what ends up in your repository.

What each account screen holds

Every row here is a surface a logged-in FE ONLINE 2.0 user actually sees. The mapping is what we normalize, not a generic finance checklist.

Ways into the data, and the one we'd run

Two routes carry real weight here, with a third as backup. We set up access with you during onboarding — a consenting account or a sandbox — so none of this is a hoop you clear before we start.

Authorized session analysis

We trace how the app authenticates and talks to its backend, then re-implement that conversation against an account whose holder has agreed. This reaches the full set above — loan, card, Übank, schedule — because it sees exactly what the app sees. Effort is moderate; durability depends on the app's release cadence, which we plan for with a re-check step. This is the route we'd actually run, because it covers both the lending and the bank legs in one session and does not wait on anyone else's roadmap.

Vietnam Open API consent channel

State Bank of Vietnam Circular 64/2024/TT-NHNN, in force since 1 March 2025 per the SBV press release, is standing up a consent-based Open API regime across the banking rail. As the Übank deposit leg exposes a regulated query and consent endpoint under that scheme, we move the bank-account half onto it — lower maintenance, formal consent records. We treat it as the path the account data migrates toward, and we wire the integration so that switch is a configuration change, not a rebuild.

User-consented export

Where the borrower can pull a statement or contract from the app, we fold that into the feed as a low-friction fallback for documents the live session does not surface cleanly.

What lands in your repository

You get a working integration, not a report. For FE ONLINE 2.0 that means:

• An OpenAPI description of the normalized endpoints — loan, card, Übank balance and movements, schedule — so your team codes against a stable contract instead of the app's raw traffic.
• A protocol and auth-flow write-up: device binding, the Smart OTP step, and the token refresh that keeps a verified session alive, documented as the app runs it.
• Runnable source for the key calls in Python or Node.js — login, session refresh, loan fetch, Übank movement pull — that you can run on day one.
• Automated tests against recorded responses, so a future app change shows up as a red test rather than a silent gap.
• Interface documentation plus data-retention and consent-logging guidance fit for Vietnamese consumer-finance data.

Session sketch

Illustrative only — field names are confirmed during the build against a consenting account, not asserted here as the production contract.

POST /auth/session            # device-bound login, Smart OTP verified
  -> { access_token, refresh_token, expires_in }

GET  /loan/accounts           # Authorization: Bearer <access_token>
  -> [ { loan_id, principal_outstanding, credit_limit,
         rate_band, term_months, next_due } ]

GET  /loan/{loan_id}/schedule
  -> [ { instalment_no, due_date, amount, status } ]   # status: paid | due

GET  /ubank/account
  -> { balance, currency: "VND", movements: [
         { ts, type: "disbursement"|"repayment"|"transfer", amount } ] }

# token nears expiry -> refresh, do not re-trigger OTP
if expires_in < 60: refresh(refresh_token)
# card PAN arrives tokenized; never reconstructed

Consent and the Vietnamese rulebook

The dependable basis for this work is the account holder's own authorization to reach data that is already theirs. On top of that sits the regulated layer: Circular 64/2024/TT-NHNN phases Open API obligations across the banking sector — information query first, then consent-based access, then payment initiation — with banks required to file deployment plans to the SBV and reach full compliance by 1 March 2027, per the regulator's published timeline. We run authorized, logged, data-minimized access: only the fields a use case needs, consent records kept, NDA in place where the engagement touches borrower identity. Tokenized card data stays tokenized end to end.

Build notes we account for

Two things about this app shape how we engineer the integration, and both are ours to handle.

• The disbursement-and-repayment loop runs across two backends — FE Credit's lending core and the Übank deposit ledger — so a repayment shows on the bank side before it clears on the loan side. We design the sync to reconcile the two legs on a stable key rather than assuming they update in lockstep, which is what keeps a repayment matched to its instalment.
• The login chain leans on Smart OTP and device binding, and the session token expires on a short window. We build the refresh around that window so the feed renews quietly instead of re-prompting for an OTP, and we add a re-validation step to maintenance so a front-end release on FE Credit's side surfaces as a failing test we fix, not a dead integration.

Cost and how to start

A runnable FE ONLINE 2.0 integration — loan, card and Übank account joined into one feed — starts at $300 for source-code delivery, and you pay after we deliver and you have run it and are satisfied. If you would rather not host anything, the alternative is our pay-per-call hosted API: you call our endpoints, you pay only for calls, nothing upfront. Either way the cycle is one to two weeks. Tell us the app and what you want out of its data at /contact.html and we handle access, the build, and the documentation from there.

Where teams put this

• A lender pre-checking a borrower's existing FE Credit exposure and repayment behaviour before extending more credit.
• A personal-finance app showing the Übank balance and the next loan instalment in one view the user already half-expects.
• A collections or servicing tool reconciling repayments against the instalment schedule without manual statement reading.

Screens we worked from

App store screenshots used while mapping the surfaces above. Tap to enlarge.

How this was checked

I worked from the FE ONLINE 2.0 store listings for the app's own description of its loan terms, Übank linkage and security model, the FE Credit corporate site for the VPBank SMBC ownership, and the State Bank of Vietnam material on Circular 64/2024/TT-NHNN for the Open API timeline. Checked June 2026; the loan figures are quoted as the app's listing states them, not independently verified.

• FE ONLINE 2.0 — Google Play listing
• FE Credit — about / VPBank SMBC Finance
• SBV — press release on Circular 64/2024/TT-NHNN
• Brankas — how Circular 64 reshapes Open Banking in Vietnam

OpenBanking Studio · integration desk mapping, June 2026.

Nearby apps in the same data space

Other Vietnamese consumer-finance apps hold comparable account data; naming them widens the picture for anyone building one feed across lenders. Listed neutrally, not ranked.

• Home Credit Vietnam — instalment and cash-loan accounts with repayment schedules.
• Mcredit — cash and instalment loans under the MB Bank–Shinsei joint venture.
• Mirae Asset Finance Vietnam — unsecured cash and vehicle loans.
• HD Saison — point-of-sale instalment and cash-loan ledgers.
• Shinhan Finance — consumer loans and card balances.
• SHB Finance — cash-loan accounts and repayment tracking.
• Lotte Finance — credit cards and consumer loans.
• JACCS Vietnam — instalment financing accounts.
• Easy Credit — unsecured cash-loan accounts.
• Viet Credit — credit-card and small-loan balances.

Questions integrators ask

Which records sit behind the FE ONLINE 2.0 login that an integration can reach?

The per-user surfaces are the cash-loan account (limit, principal, repayment schedule, instalment due dates), the FE Credit credit card (balance, statement, cash-advance status) and the linked Übank digital-bank account where disbursements land and repayments are pushed. Stored loan contracts and the payment calendar are also account-bound. Those are the domains we normalize into one feed.

Is FE Credit data in scope of Vietnam's Open API rules?

FE Credit operates as VPBank SMBC Finance, and the Übank leg is a deposit-side bank account. State Bank of Vietnam Circular 64/2024/TT-NHNN sets a phased Open API regime — information query, consent-based access, then payment initiation — that bank-rail data falls under. Where a regulated consent channel is live we use it; otherwise the dependable basis is the account holder's own authorization to act on their data.

How do you handle the Smart OTP and facial-recognition steps in the login chain?

We map the auth flow as the app actually runs it — device binding, Smart OTP issuance and the token refresh that follows a verified session — and drive it through a consenting account during the build. Tokenized card numbers stay tokenized; we never reconstruct a PAN. The result is a documented session model your service can re-run, not a stored credential.

Can the Übank balance and the FE Credit loan show up in one schema?

Yes. The disbursement-to-Übank and repayment-from-Übank flow is the reason most clients want both legs joined. We deliver a single normalized object that carries the loan account, the card and the Übank balance and movement history, so a downstream system reconciles a repayment against its source instalment without stitching two feeds by hand.