Connecting Oriental Bank when the aggregators do not reach it

Banca Movil from Oriental Bank lives inside the FIS Digital One stack (the Android package id is com.fisglobal.d1obmobile, per its Play Store listing), and the bank itself is a subsidiary of OFG Bancorp, an NYSE-listed holding company. None of that would matter to an integrator on its own, except that Plaid's Puerto Rico coverage today lists Banco Popular and FirstBank and stops there. If your product needs Oriental Bank, an aggregator is not the path. We talk to the app under the customer's authorization instead, and ship the result as source.

What the app actually holds

Most of what an integrator wants from a retail-banking app is variations on the same five or six tables. Banca Movil exposes them through the Spanish/English app surface described on the bank's own mobile-banking pages.

The routes that genuinely apply here

Three approaches are realistic for Oriental Bank. One is what we recommend.

1. Authorized protocol analysis of the Banca Movil app

This is the spine. The studio captures the auth chain (login, MFA challenge, token issuance, refresh) and the per-tenant request shape that Oriental Bank ships on top of FIS Digital One, then replays the calls as a server-side client under the consenting customer's session. Coverage is broad: balances, transactions, statement PDFs, transfers, FOTOdeposito, card controls. Durability is fair — FIS tenants tend to ship per-field churn between releases rather than full route renames, and the regression suite catches that.

2. User-consented credential session

Suitable when a single account holder wants their own data piped into something they control (a personal-finance dashboard, a tax tool, a treasury rollup). The account holder consents, the integration logs in on their behalf, and the API exposes their data only. MFA is handled in-flow; we do not store passwords longer than the active session.

3. Native export as a passive fallback

End-of-cycle E-Statements are PDFs the customer can already download. For an archive-only or bookkeeping use case where live state is not required, we can stand up a PDF pipeline alone — cheaper, less surface area, no live session needed. The trade-off is the cycle-close latency. Most callers want route 1.

Why not Plaid or Tink as the main route? Because Oriental Bank is not in Plaid's Puerto Rico coverage list, and the same holds across the major aggregators today. The aggregator path is a real option for Banco Popular or FirstBank; it is not one for this app.

What lands on your side

A delivery for Oriental Bank usually contains:

• An OpenAPI 3.1 specification covering the routes that matter for the use case — typically authentication, accounts, transactions, statement fetch, transfer initiation, People Pay submission, FOTOdeposito submission, card controls.
• Runnable client source in Python and Node, with the auth dance (login → MFA → refresh) factored into a single retrying session object.
• A protocol and auth-flow report: the OAuth/token/cookie chain as it actually behaves on this tenant, including the per-tenant headers and any signed-payload fields confirmed during the build.
• An automated test suite that runs against a consenting account or sponsor sandbox, covering happy paths and the rate-limit and cap behaviors below.
• Interface documentation written for the integrator, plus a one-page operations note for the team that will run it — consent renewal cadence, log retention, what to watch when Banca Movil ships a new release.
• Compliance and data-retention guidance scoped to PR / FDIC / OCIF posture, and a short NDA template where the client wants it.

A request, end to end

Shape only — exact parameter names, header set, and the precise MFA cassette get pinned during the protocol pass. The point is the chain, not these literal paths.

# 1. Login. Banca Movil issues an access token plus a refresh token,
#    and may return an mfa_challenge that has to be cleared before the
#    token is usable against the data endpoints.
POST /banca-movil/api/v3/auth/login
  body: { user, password, device_id }
  -> { access_token, refresh_token, mfa_challenge?: { id, channel } }

# 2. Clear MFA (push, OTP, or out-of-band depending on the channel).
POST /banca-movil/api/v3/auth/mfa
  body: { challenge_id, otp }
  -> { access_token, refresh_token }

# 3. Pull the account list.
GET /banca-movil/api/v3/accounts
  Authorization: Bearer <access_token>
  -> [{ account_id, type, currency, balance_available,
        balance_current, masked_number }]

# 4. Transactions for one account, date-range scoped.
GET /banca-movil/api/v3/accounts/{account_id}/transactions
       ?from=2026-04-01&to=2026-04-30
  -> [{ tx_id, posted_at, amount, description,
        balance_after, channel }]

# 5. Refresh on 401.
POST /banca-movil/api/v3/auth/refresh
  body: { refresh_token } -> { access_token }

# 6. People Pay submission. Caps $2,000 per transaction and $4,000
#    per day, per the bank's published terms; the client refuses
#    over-cap requests locally rather than letting the bank reject them.
POST /banca-movil/api/v3/people-pay/transfers
  body: { from_account_id, recipient, amount, memo }
  -> { transfer_id, status }

Things this build accounts for

A few specifics shape how the integration is written for this app rather than a generic FIS tenant.

• FIS Digital One tenancy. The package id com.fisglobal.d1obmobile places Banca Movil on FIS's Digital One stack. The auth chain and route shape are template-similar across FIS-hosted banks, but the per-tenant header set, signed-payload keys, and exact route segments are unique to OFG Bancorp's deployment. We pin those during the protocol pass instead of assuming a generic FIS schema; that is the bulk of the engineering hours on the first build.
• Bilingual response payloads. The app serves both English and Spanish, and a small number of enum values and field labels arrive localized depending on the session locale. The client pins one locale at the API boundary so downstream consumers see a single canonical set of strings.
• Cap-aware client. FOTOdeposito caps run at $6,000 per check, $12,000 per day, $24,000 per twenty-five days, plus ten checks per day and thirty per month (per the Oriental Bank FOTOdeposito page). People Pay caps at $2,000 per transaction and $4,000 per day. The SDK refuses over-cap calls before they hit the bank, so a misconfigured caller fails fast and locally instead of producing a generic bank rejection that has to be debugged by hand.
• E-Statement cadence. Statements appear at cycle close, not continuously. The integration knows the cycle window, polls around close, and retries if the document is delayed; bookkeeping pipelines see a clean once-per-cycle event rather than a noisy poll.
• Release-gate suite against the live app. Banca Movil ships updates regularly. We keep a tagged set of expected responses in CI and run it against the live tenant on a schedule, so a renamed field or added header breaks first there.

Authorization, OCIF and FDIC

Oriental Bank is an FDIC member, supervised by Puerto Rico's Office of the Commissioner of Financial Institutions. US KYC and AML rules apply on the island the same way they apply on the mainland. The integration is built and operated on that footing: every session is bound to a specific consenting customer, logged, scoped to the data the use case actually needs, and revocable.

On the federal data-rights question: the CFPB's Personal Financial Data Rights rule (12 CFR Part 1033) is, as of this writing, enjoined and back in agency reconsideration — the Eastern District of Kentucky stayed enforcement, and the CFPB's August 2025 Advance Notice of Proposed Rulemaking on reconsideration closed for comment in October 2025 with no replacement rule issued. None of the rule's specific obligations are in force right now, and where it lands is unsettled. The integration's footing is the customer's own authorization to access their own data, which is the dependable basis today regardless of how the §1033 reconsideration concludes.

Sources and review

Page checked against the live bank pages and primary regulatory sources on 30 May 2026. Specifically: the Oriental Bank FOTOdeposito product page for the per-deposit, per-day, and per-month caps; the Oriental Bank People Pay terms for the $2,000 / $4,000 caps; OCIF for the supervisory framing; and the Federal Register for the §1033 reconsideration timeline.

• Oriental Bank — FOTOdeposito (limits and terms)
• Oriental Bank blog — FOTOdeposito and People Pay limits
• OCIF — Puerto Rico Office of the Commissioner of Financial Institutions
• Federal Register — Personal Financial Data Rights Reconsideration (Aug 2025)

Reviewed May 2026 by the OpenBanking Studio integration desk.

Other Puerto Rico banking apps in the same data surface

Useful context if your roadmap covers more than Oriental Bank, since the data shape is similar across the island's retail-banking estate.

• Mi Banco (Banco Popular de Puerto Rico) — the largest PR retail-banking app; same balance, transaction, transfer, statement surface. Plaid covers this one.
• FirstBank Puerto Rico Digital Banking — FDIC and OCIF; deposit and transfer surfaces map cleanly to the same canonical schema. Plaid covers this one too.
• PenFed Mobile — federal credit union serving PR members; member-facing balances, statements, card controls.
• Caribe Federal Credit Union mobile — PR cooperativa app with the standard member-aggregation set.
• Oriental Biz — Oriental Bank's business-banking app; same back end, different surfaces (ACH origination, positive pay, treasury reporting).
• Banesco USA Mobile — Florida-headquartered bank with a Hispanic-Caribbean customer base often paired with a PR account.
• Citi Mobile — large US bank used in PR alongside a local primary.

These names are listed for ecosystem context. We do not rank or compare them, and an integration we build for one of them is scoped to that bank.

Interface evidence

Screenshots from the public Play Store listing. Click to enlarge.

Questions an integrator usually asks first

Why not just connect through Plaid?

Plaid's Puerto Rico coverage lists Banco Popular and FirstBank (per the Plaid institutions docs and the OpenBankingTracker country page) and does not include Oriental Bank, so an aggregator route is not a realistic spine for this one. We talk to Banca Movil directly under the customer's authorization instead.

Will the build survive Oriental Bank pushing a new Banca Movil release?

We keep a regression suite pinned against the live app so the next release breaks first in CI rather than in your production. Tenants on the FIS Digital One stack tend to ship per-field churn (renamed enums, added headers) more often than full route changes; the suite watches both.

Can FOTOdeposito be triggered from the integration?

Yes, within the published caps: $6,000 per check, $12,000 per day, $24,000 per twenty-five days, with ten checks per day and thirty per month (per the Oriental Bank FOTOdeposito page). The client refuses requests over the cap at the SDK layer so a misconfigured caller does not just see a generic bank rejection.

How does this read against CFPB Section 1033?

As of this writing the CFPB Personal Financial Data Rights rule is enjoined and back under reconsideration; the agency's August 2025 Advance Notice (per the Federal Register) closed for comment in October 2025 and no replacement rule is out. The integration's footing is the customer's own authorization, which is unaffected by where the rule lands.

Does the integration cover Spanish-language field labels?

Banca Movil serves both English and Spanish, and a few enum values and labels arrive localized; we pin the API locale so downstream consumers see one canonical set of strings rather than a mix.

Source code for the build ships as the OpenAPI spec, runnable Python and Node clients for the surfaces above, an auth-flow report, the test suite, and the interface docs. Price starts at $300 and is billed after delivery, once you have run it against the use case and are satisfied. If you would rather not host any of it, the studio runs the integration as a hosted API and bills per call with no upfront fee. The build cycle is one to two weeks. Tell us the use case at /contact.html — just the app name and what you need from its data is enough to start; access, sandboxes and any compliance paperwork are arranged with you during onboarding.