Account, statement, and transfer data from Oriental Bank's app

The job most teams bring us for Oriental Bank is a clean first load of an account's full history, then keeping it current without re-reading everything. That order — bulk backfill first, small delta after — drives the whole design. Banca Móvil holds the things you would expect of a primary-account banking app: live balances across deposit and card products, posted transaction history, end-of-cycle e-statements, recurring transfers, People Pay person-to-person records, and links to external accounts the customer has added.

The route we take is authorized interface integration: with the account holder's consent, we map the exact traffic the FIS Digital One app exchanges with its backend and rebuild the read calls as a small, documented client. The bank's parent is OFG Bancorp, and the listing describes it as a Member FDIC institution — Puerto Rico sits under US federal banking rules, so the legal footing is the consumer's own right to their own data, not a regional open-banking scheme. Below: what data is reachable, how a backfill actually looks, what ships, and where the regulation stands.

What lives behind the login

These are the surfaces the app exposes once a session is established. Granularity reflects how Banca Móvil presents each one to the customer.

How we reach it

Two routes genuinely fit a FIS-backed bank app, plus a fallback. We name the one we would actually run.

Authorized interface integration (recommended)

With the customer's consent, we observe the session the Banca Móvil app opens against the FIS Digital One backend, document the auth and token-refresh chain, and rebuild the read endpoints as a maintainable client. Reachable: everything in the table above, at the same fidelity the app shows. Effort is moderate and front-loaded into the mapping pass; durability is good as long as we watch for backend version changes, which we account for in maintenance. This is the route we recommend, because it gives you balances, transactions, and statements directly rather than a lowest-common-denominator export.

User-consented aggregation

Where you only need normalized balances and transactions and want to stand it up fast, a consent-based aggregation path can cover Oriental Bank as one of several institutions. Reachable surface is narrower — typically balances and transaction lines, not full e-statement documents or card state — but it is quick to wire and durable. We use it when breadth across banks matters more than depth on this one.

Native e-statement export (fallback)

The app produces end-of-cycle e-statements the customer can retrieve. As a fallback we can parse those documents into structured records. It is the most limited route — cycle-grained, document-shaped — but useful for a statement archive where a live feed is not required.

A backfill, sketched

This is the shape of the history walk, not a copy of any Oriental Bank endpoint. Field names and the auth method are confirmed against the live app during the build; what follows is illustrative.

# Authorized read client — Oriental Bank (Banca Móvil) history backfill
# Auth chain (login -> session token -> refresh) is mapped during the build.

client = OrientalSession(token=consented_token)   # account holder consented

def backfill(account_id, oldest="2019-01-01"):
    cursor = None
    while True:
        page = client.get_transactions(
            account_id=account_id,
            window_end=cursor,        # walk backward, dated windows
            page_size=200,
        )
        for tx in page.items:
            # tx.posting_ref is the bank's own reference for the row;
            # upsert on it so an overlapping re-run updates instead of duplicating.
            store.upsert(account_id, tx.posting_ref, normalize(tx))
        if not page.has_more or page.oldest_date <= oldest:
            break
        cursor = page.next_window

    # statements are document-grained, pulled separately
    for stmt in client.list_estatements(account_id):
        store.put_statement(account_id, stmt.cycle, stmt.pdf)

# after the backfill, the delta job reuses get_transactions()
# with window_end = last_seen_cursor, on a daily or hourly tick.

The normalize step maps Banca Móvil's category and amount fields into a single schema, so a transaction from Oriental Bank lines up with one from any other institution in the same store.

What you get

Delivery is code first. The package is built around your ingestion need, not a generic spec.

• Runnable source — a Python or Node.js client for the read surfaces you need (balances, transactions, e-statements, transfers), with the backfill and delta jobs wired and ready to run.
• Webhook / scheduler handlers — the glue that drives the delta pull on your cadence and hands normalized rows to your store or queue.
• Automated test harness — fixtures over recorded responses so a backend change in Banca Móvil shows up as a failed assertion before it reaches your pipeline.
• Normalized schema — the mapping from Oriental Bank's fields to your unified transaction and statement model.
• OpenAPI / auth-flow report — the documented login, token, and refresh chain plus an OpenAPI description of the rebuilt read endpoints.
• Interface docs and retention guidance — how to operate it, and how to keep consent records and minimize stored data.

Where the authorization stands

The dependable basis here is simple: the account holder authorizing access to their own Oriental Bank data. Puerto Rico is US federal territory for banking, and the parent is a Member FDIC institution per the app's listing, so the operative frame is consumer consent rather than a local open-banking mandate.

The forward-looking piece is the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033). It was finalized but is currently enjoined and back in CFPB reconsideration, with the underlying litigation stayed — so it is not in force and we do not present it as the governing framework. If and when it settles, a consent-based integration like this one slots into it cleanly; until then, consent is the footing. We keep consent records, log access, minimize what we retain, and sign an NDA where the engagement calls for one.

Build notes specific to this app

Two things about Oriental Bank shape how we build, and we handle both inside the engagement rather than handing you a checklist.

• FIS Digital One versioning. The app runs on FIS's Digital One platform (per FIS's product page and the com.fisglobal.d1obmobile package), which ships periodic backend updates. We pin the read client to the observed session contract and keep the test fixtures current, so a Digital One upgrade is caught and patched rather than silently breaking your feed.
• Bilingual category labels. Banca Móvil runs in English and Spanish, and category and statement labels differ by the customer's language setting. We normalize on stable identifiers, not the display string, so a Spanish-locale account and an English-locale account map into the same schema.
• Read versus action surfaces. We treat balances, transactions, and e-statements as the read core and arrange access with you during onboarding — against a consenting account. Write actions in the app (card block, PIN change, Remote Check Deposit) are scoped separately, only with per-action consent, because the risk profile is different.

Where this usually goes

• A Puerto Rico accounting or bookkeeping tool that needs every Oriental Bank posting categorized and pushed nightly into its ledger.
• A lender pulling a consenting applicant's e-statements and transaction history to underwrite, then dropping the feed once the decision is made.
• A personal-finance app aggregating Oriental Bank alongside other Puerto Rico institutions into one normalized balance-and-transaction view.
• A treasury dashboard for a business that banks with Oriental and wants positions refreshed through the day rather than checked by hand.

From the app

Screens from the public Play Store listing, shown to ground which surfaces the integration targets.

Similar apps in the same space

If you are aggregating Puerto Rico banking, these come up alongside Oriental Bank. Named for context, not ranked.

• Banco Popular — Mi Banco: the island's largest bank; balances, transactions, payments and transfers behind a customer login.
• FirstBank — Tu Banca Digital: deposit and card data with mobile deposit, transfers, and check services.
• Citibank (Puerto Rico): retail accounts, statements, and card data within Citi's digital banking.
• CooPACA Móvil: Arecibo credit-union cooperative; balances, e-statements, P2P, and transfers for members.
• Caribe Federal Credit Union: member accounts, transactions, and statements for a federal-employee membership.
• PenFed Credit Union: checking, savings, loans, and cards for eligible members, including in Puerto Rico.
• Oriental Biz: Oriental's business-banking app; commercial account and cash-management data from the same group.

Questions integrators ask

How do you handle a first-time backfill versus keeping the data fresh afterward?

Two different jobs. The backfill walks the account history in date-windowed pages until it reaches the oldest available cycle, writing every posted transaction and e-statement once. After that, a short delta job pulls only the window since the last cursor — daily or hourly, whichever your use case needs. Each posted row carries the bank's own reference, so re-running a backfill over an overlapping window updates in place rather than inserting duplicates.

Oriental Bank's app runs on FIS Digital One — does that shape the work?

It does, and it helps. The Android package com.fisglobal.d1obmobile and FIS's own Digital One product page point to a FIS-hosted backend with a recognizable session, token, and money-movement surface. We map the actual login and token-refresh chain the app uses, then build the read endpoints against that, rather than guessing at a generic shape.

In Puerto Rico, what is the legal basis for reading my Oriental Bank data?

The dependable basis is the account holder's own authorization to access their own data — Puerto Rico falls under US federal banking rules, and Oriental Bank is a Member FDIC institution per its app listing. The CFPB Personal Financial Data Rights rule (12 CFR Part 1033) may formalize this later, but it is currently enjoined and back in agency reconsideration, so we do not build on it as settled law. We work from consent, keep consent records, and minimize what we store.

Can you reach card controls and Remote Check Deposit, or only balances and statements?

Read surfaces — balances, transaction history, e-statements, transfer and People Pay records, scheduled payments — are the straightforward part and what most integrations need. Action surfaces like card block, PIN change, and Remote Check Deposit exist in the app but are write operations with extra risk; we scope those case by case and only with explicit account-holder consent for each action.

A first transaction-and-statement pull, with normalized output and tests, lands in one to two weeks. From there you can take it either way: we deliver the runnable source outright from $300, payable after delivery once it works for you, or you skip the build and call our hosted endpoints with no upfront fee, paying only per call. Tell us the account data you need and we will scope it — Start a Oriental Bank integration

What was checked

Reviewed on 2026-06-07 against the app's public listing, the bank's own digital-banking pages, the FIS Digital One product page, and the current CFPB rulemaking record. Sources opened:

• Oriental Bank on Google Play (package, feature list)
• Oriental Bank — Mobile and Online Banking
• FIS Digital One product page
• Section 1033: open-banking rule enjoined and under reconsideration

Reviewed 2026-06-07 — OpenFinance Lab, integration engineering notes.