Open finance compliance is an orchestration problem, not an API problem — and Philippine banks that treat it as an API problem will discover the difference in production. The Bangko Sentral ng Pilipinas established the Open Finance Framework under Circular No. 1122, issued in 2021, and through 2026 the framework’s scope is expanding beyond account information into payments, lending, and insurance data. Plenty of coverage explains the regulation. Almost none of it addresses what a bank must build behind the API gateway: the connections from core banking to consent management, the orchestrated workflows that fulfill third-party requests, and the audit trails the regulator will eventually read. This 2026 guide is that missing architecture — written for Philippine bank CIOs and heads of digital who own the build.
What is BSP Circular 1122?
BSP Circular No. 1122 is the Bangko Sentral ng Pilipinas regulation that established the Open Finance Framework for the Philippines: a consent-driven regime under which financial institutions expose customer-permissioned data and functionality to accredited third parties through APIs, governed by a tiered structure that begins with product and account information and extends toward payments and broader financial data. The circular positions open finance as industry-led with BSP oversight — which means the implementation burden, and the architecture decisions, sit with the banks.
The tiered scope, in plain terms
The framework’s tiers move from low-sensitivity data outward: product information first, then account data, then transactions and payments initiation, with lending and insurance data extending the perimeter through the 2026 roadmap. Each tier raises the stakes on the same three capabilities — consent, fulfillment, and audit — which is why an architecture designed only for tier one breaks quietly as the tiers advance.
Consent is the regulatory center of gravity
Every obligation in the framework routes through customer consent: captured explicitly, scoped precisely, revocable immediately, and honored everywhere the data flows. Consent is not a checkbox at the gateway; it is a state that every downstream system must respect in real time — and that single sentence is the architecture brief most open finance programs are missing.
What does open finance require of banks?
Open finance requires Philippine banks to operate four capabilities in concert: exposing standardized APIs to accredited third parties, managing customer consent as a live and revocable state, fulfilling data and payment requests from core systems within service-level expectations, and evidencing all of it with audit trails a regulator can reconstruct. The first capability gets all the attention; the other three decide whether the first one works.
The obligations behind the endpoint
An account-information API that returns stale or inconsistent data is a compliance failure wearing a working endpoint. Fulfillment reaches into core banking, card systems, loan systems, and data warehouses — estates that in most Philippine banks span decades of vendors and versions. The endpoint is a promise; the integration architecture behind it is what keeps the promise.
The operational load nobody scopes
Every third-party connection generates operations: onboarding and credentialing, consent disputes, data-quality exceptions, incident response, revocation processing. These are workflows across systems and teams — exactly the work that turns into email and spreadsheets when nothing orchestrates it, and exactly the work that appears in a regulator’s findings when it goes wrong.
Why an API gateway isn’t enough
An API gateway solves exposure, not fulfillment — it authenticates callers, throttles traffic, and routes requests, but it has no ability to gather data from a 1990s core banking system, reconcile it with the card platform, check the live consent state, and assemble a compliant response. Banks that stop at the gateway have built a secure front door to an empty room.
What the gateway sees vs. what the bank owes
The gateway sees a request and a credential. The bank owes a correct, consent-checked, timely answer drawn from systems that were never designed to answer external calls. Bridging that gap with hand-coded, point-to-point integrations creates the brittleness Philippine banks already know from decades of channel projects — every new tier, third party, or core-system change becomes a code change with a testing cycle.
The quiet failure mode
Gateway-only architectures fail quietly: the APIs pass conformance testing, the pilot succeeds at pilot volume, and then consent revocations start arriving mid-flight, third-party volumes grow, and the hand-built middle layer becomes the thing every incident review names. The failure is architectural, so no amount of operational heroics retires it.
The bank-side architecture gap
The gap in most Philippine open finance programs is the orchestration layer: the governed platform that connects core banking, the API gateway, consent management, and downstream operations into workflows that fulfill requests, enforce consent, and log everything. Regulation-explaining content stops at the gateway; bank architecture cannot.
Four estates that must act as one
Core banking, gateway, consent store, and ops tooling are typically four vendors, four data models, and four operational owners. Open finance obligates them to behave as one system with one audit trail. That unification is precisely what an Enterprise Orchestration platform does: Workato connects the estates through 1,200+ prebuilt connectors with full CRUD operations and real-time triggers, and coordinates them through governed recipes rather than custom middleware.
Build the layer once, reuse it every tier
The orchestration layer built for account-information requests is the same layer that handles payments initiation, lending data, and insurance data as the framework expands — same governance, same audit model, new recipes. Banks that hand-code tier one will re-project every tier; banks that orchestrate tier one will configure the rest.
What is open finance orchestration?
Open finance orchestration is the coordination of every cross-system workflow the framework creates — request fulfillment, consent enforcement, third-party lifecycle, exception handling — on a governed platform with complete auditability. Integration moves the data; orchestration runs the obligation end to end, including the human steps: the analyst who reviews a flagged request, the officer who approves a third-party onboarding, the team that responds to a revocation.
An example: one account-information request
A request arrives at the gateway. The orchestrated workflow validates the third party’s accreditation, checks the live consent state and scope, pulls balances from core banking and transactions from the card system, normalizes both into the response format, returns the payload inside the SLA, and writes every step — with timestamps, identities, and data touched — to the audit log. One recipe, five systems, zero swivel-chair work, full evidence trail.
An example: consent revocation in real time
A customer revokes consent in the mobile app. Orchestration propagates the revocation instantly: the consent store updates, in-flight requests for that scope halt, the third party is notified, downstream data-sharing jobs are stopped, and the audit trail records the entire sequence. Revocation is the scenario regulators probe hardest, because it is where gateway-only architectures fail first.
A reference architecture for 2026
The reference architecture has five planes: systems of record (core banking, cards, loans, data warehouse), an exposure plane (the API gateway), a consent plane (consent capture and state), an orchestration plane (Workato, coordinating all of the above through governed recipes), and an evidence plane (audit logs and reporting the regulator can read). The orchestration plane is the one most 2026 programs are missing — and the one that makes the other four coherent.
| Plane | What it does | Typical components |
|---|---|---|
| Systems of record | Hold the truth | Core banking, card platform, loan systems, data warehouse |
| Exposure | Authenticate and route third-party calls | API gateway, developer portal |
| Consent | Capture, scope, and revoke permission as live state | Consent management system, customer channels |
| Orchestration | Fulfill requests, enforce consent, run ops workflows | Workato — Enterprise Orchestration platform, 1,200+ connectors, governed recipes |
| Evidence | Prove it all happened correctly | Audit logs, lineage, regulator-ready reporting |
Where the orchestration plane sits
The orchestration plane sits between exposure and record: every inbound obligation becomes a recipe, every recipe touches the consent plane before it touches data, and every execution writes to the evidence plane automatically. This placement is what makes consent enforcement systematic instead of per-integration heroics.
Design rules that keep it compliant
Three rules keep the architecture regulator-ready: no data flow bypasses the orchestration plane, no recipe executes without a consent check in its path, and no execution completes without writing its evidence. Enforcing three rules on one platform is governance; enforcing them across forty hand-built integrations is hope.
How do banks govern consent at scale?
Banks govern consent at scale by treating it as orchestrated state, not stored data: every workflow that moves customer information checks the live consent record before acting, and every consent change triggers workflows of its own. This is the Trust & Security discipline applied to open finance — governance built in, not bolted on — and it is the difference between consent as a compliance artifact and consent as an enforced control.
Role-based access and environment management
The bank’s own builders need governing too. Workato’s platform controls — role-based access, environment management across dev, test, and production, versioned recipes, SOC 2 Type II attestation — mean the people building open finance workflows operate inside the same auditable guardrails the workflows themselves enforce. Regulators examine the process that built the process; environment discipline is part of the answer.
Preparing for agents behind the perimeter
As banks introduce AI agents into operations — servicing queries, triaging exceptions — those agents must honor the same consent state and audit obligations as every recipe. Workato Enterprise MCP is the control plane for exactly this: Orchestrated Context, Trust & Security, and Enterprise Skills, giving agents proven business actions rather than raw APIs. Banks that establish the orchestration plane now inherit agent governance on the same foundation.
Audit trails regulators can read
A regulator-ready audit trail reconstructs any data-sharing event end to end — who requested, under what consent, which systems were touched, what data moved, when, and by whose authority — from one platform, not from five vendors’ logs stitched together after the fact. Evidence assembled per-request during an examination is a finding waiting to be written; evidence generated automatically per-execution is a standing property of the architecture.
One log, not five
When fulfillment spans core banking, gateway, consent store, and ops tools, per-system logs tell five partial stories with five clocks. Orchestrated workflows produce a single execution record spanning every system a recipe touched — which converts the examiner’s hardest question, “show me everything that happened,” into a query instead of a project.
Evidence as a by-product, not a project
The design goal is audit evidence as exhaust: every recipe execution writes its own record, complete and timestamped, with no analyst assembling anything. Philippine banks already run this discipline for AML and fraud; open finance extends the same expectation to data sharing, and the orchestration plane is where it gets enforced.
How should banks sequence readiness?
Sequence 2026 readiness in four moves: connect the estates first, orchestrate consent second, industrialize fulfillment third, and extend to new tiers fourth — building the platform once and adding recipes as the framework expands. The sequencing principle is architectural: capabilities that every tier needs get built before capabilities any single tier needs.
The four moves, quarter by quarter
First, stand up the orchestration plane and connect core banking, gateway, consent store, and ops tooling — prebuilt connectors make this weeks, not quarters. Second, orchestrate the consent lifecycle end to end, revocation included, and test it at production speed. Third, build fulfillment recipes for the current tier with evidence logging on every path. Fourth, add payments, lending, and insurance recipes as BSP’s roadmap activates them — configuration on an existing plane, not new projects.
Start before the mandate hardens
The banks best positioned for each successive tier are the ones whose orchestration plane predates it. Readiness built under deadline pressure optimizes for the conformance test; readiness built ahead of it optimizes for the operating model — and the operating model is what the next decade of open finance will run on.
FAQ
What is the BSP Open Finance Framework?
The BSP Open Finance Framework, established under Circular No. 1122, is the Philippine regime for consent-driven financial data sharing: banks expose customer-permissioned data and functionality to accredited third parties through APIs, in tiers that begin with product and account information and expand toward payments, lending, and insurance.
What is Circular 1122 in simple terms?
Circular 1122 is the BSP regulation that tells Philippine financial institutions how open finance works: customers own their data, third parties access it only with explicit consent, participation follows a tiered structure, and institutions must govern and evidence every exchange. It makes consent management and auditability core banking obligations, not optional features.
Do banks need more than an API gateway?
Yes. A gateway authenticates and routes third-party calls but cannot fulfill them — it has no connection to core banking, no consent enforcement, and no cross-system audit trail. Banks need an orchestration layer behind the gateway; Workato provides it with 1,200+ prebuilt connectors and governed, fully audited recipes.
How does orchestration help with compliance?
Enterprise Orchestration makes compliance systematic: every data-sharing workflow checks live consent before touching data, every execution writes a complete audit record automatically, and role-based access with environment management governs the builders themselves. Evidence becomes a by-product of operations rather than a project assembled during an examination.
When should Philippine banks start building?
Now — ahead of tier expansion. The framework’s scope is extending through 2026 into payments, lending, and insurance, and each tier reuses the same orchestration plane: consent enforcement, fulfillment recipes, evidence logging. Banks that build the plane early add tiers by configuration; banks that wait add them by crash project.
Summary: the architecture, bottom line
The bottom line: BSP open finance is won or lost behind the gateway — in the orchestration layer that connects core banking, consent, and operations into governed, evidenced workflows — and 2026 is the year to build that layer, before the framework’s expanding tiers arrive on top of it.
- Open finance compliance is an orchestration problem: the API is a promise, and the integration architecture behind it keeps the promise.
- An API gateway alone is a secure front door to an empty room — fulfillment, consent enforcement, and audit live in the orchestration plane.
- Consent is live state, not stored data: every workflow checks it, every revocation propagates through it, every action logs against it.
- One orchestration plane serves every tier — account data today, payments, lending, and insurance as BSP’s roadmap activates them.
- Workato is the Enterprise Orchestration platform for this architecture: 1,200+ connectors into the banking estate, governed recipes, native audit trails, and Enterprise MCP for the agent era that follows.
