Most banks with a microservices architecture reach the same inflection point: the mobile team needs a dashboard screen that requires data from three services, assembled into a shape the domain service teams have no interest in maintaining. The initial solution is to let the mobile app call all three services directly and assemble the response on the device. This works until one of the services responds slowly and the screen load time becomes unacceptable. Then the mobile team asks for a dedicated endpoint that returns everything the screen needs, pre-assembled. The domain service team declines, citing their service charter. The API team proposes a generic aggregation endpoint that also serves the web portal. The open banking team raises a concern about what data a TPP should be allowed to see through that same endpoint. The discussion runs for two quarters and the mobile team’s screen still loads in 3.2 seconds.
The Backend-for-Frontend (BFF) pattern exists to end this discussion before it starts. Each channel — mobile, web, open banking — has a dedicated aggregation layer that it owns, that it deploys independently, and that it designs for its own consumers without coordinating with the owners of other channels. The domain services remain stable and channel-agnostic. The aggregation is the channel team’s problem and the channel team’s opportunity.
What the decision actually is
The surface-level framing of this decision is technical: one generic API versus dedicated BFFs. The correct framing is organisational: who owns the shape of the API that a channel consumes?
If the answer is “the domain service team,” the channel is a consumer of an API designed for the general case. When the mobile team needs a field renamed, an optional field added, or a response assembled from two services in a single call, they submit a request to the domain service team’s backlog. The domain team weighs the request against their other priorities and the needs of all other consumers. Changes happen at the domain team’s pace, not the channel team’s pace. The channel team’s ability to improve the customer experience is bounded by the slowest team in the dependency chain.
If the answer is “the channel team,” the BFF is that team’s property. They design it, deploy it, change it, and operate it. When they need the dashboard response to include a field from a new service, they add the call to their BFF. The domain service teams are unaffected. The channel team ships the feature in the next sprint. The BFF is the technical expression of team autonomy.
The choice between a generic API and a BFF is not a choice between simplicity and complexity. It is a choice between whose complexity is visible and whose is hidden. With a generic API, the channel team's aggregation logic lives in the client. With a BFF, it lives in a server-side service they own. The server-side version is easier to observe, easier to cache, easier to circuit-break, and easier to change without a mobile app release cycle.
What the regulator cares about
SAMA’s Open Banking framework and the FAPI 2.0 security profile it mandates create a compliance dimension to the BFF decision that is not present in a purely internal channel context. When a third-party provider (TPP) accesses a customer’s account data through an open banking API, the data returned must be scoped to what the customer has explicitly consented to share. An AIS (Account Information Service) token authorises access to account balances and transaction history. It does not authorise access to pending payment status, scheduled transfers, or credit limit information unless the customer has specifically consented to those fields being shared with that TPP.
The BFF is the correct place to enforce this consent-scope filtering. The underlying domain services — the Accounts API, the Payments API — have no concept of per-TPP consent. They return all data for an authenticated customer. If the open banking channel calls these services directly and applies consent filtering in the client or at the gateway, the filtering is applied after the data has been fetched, at a layer that is not controlled by the bank. Any misconfiguration exposes data the customer did not consent to share.
An Open Banking BFF that reads the customer’s consent record, calls only the domain services the consent authorises, and returns only the fields within the consented scope is a control that can be demonstrated to a SAMA examiner with a single service. The consent filtering logic is in one place, versioned in one repository, audited in one deployment pipeline, and logged in one service’s audit trail. The examination question “how do you ensure a TPP only receives data the customer consented to share?” has a clean, demonstrable answer: the Open Banking BFF, which enforces consent at the response-assembly layer before any data leaves the bank’s controlled infrastructure.
Per-channel audit logs are a related compliance requirement. The mobile channel’s BFF logs every dashboard request, with the customer ID, the fields returned, and the timestamp. The open banking BFF logs every TPP request with the TPP identity, the consent reference, the scopes applied, and the fields returned. These logs are separate, channel-specific, and directly correlate to the channel’s API contract. A shared generic API produces a single audit log where mobile, web, and open banking requests are interleaved — extracting a TPP-specific access history for a SAMA audit requires filtering a mixed log by client ID, which is operationally fragile.
The business trade-off
The argument against BFFs is surface area: three channels mean three BFF services to deploy, monitor, and upgrade. When a downstream domain service changes its API, three BFFs may need updating instead of one. When a security vulnerability is discovered in the BFF framework, three services need patching. The operational overhead is real.
The counter-argument is the cost of the alternative. A single generic API for all channels is a lowest-common-denominator API. It must serve the most demanding consumer (the web portal, which needs full data across multiple services) while not over-exposing data to the least privileged consumer (the open banking TPP, which should see only consented fields). The result is an API that is too heavy for mobile, too light for desktop, and too permissive for open banking — and which must satisfy all three simultaneously. Every change to the API requires coordination across all three channel teams to validate that nothing breaks. The release cadence is the slowest of all three.
The BFF model accepts higher surface area in exchange for lower coupling. Each BFF can be deployed, scaled, and changed independently of the others. A mobile BFF can be rewritten from IBM ACE to Spring Boot without affecting the web portal. The open banking BFF can implement a breaking API change for TPPs without requiring the mobile app to release a new version. The surface area is real; the coupling reduction is real too, and in a bank where mobile, web, and open banking are owned by teams with different release cadences, the coupling cost of a shared API is typically higher than the surface area cost of three BFFs.
What leadership must own
The BFF decision has three organisational implications that leadership must resolve explicitly. Engineering can implement whatever architecture leadership decides on; it cannot resolve the organisational questions that determine whether the BFF model succeeds or degrades into the same shared-API problems it was meant to solve.
Channel team ownership model. The mobile BFF must be owned by the mobile channel team — not by a shared integration team that also owns the web BFF and the open banking BFF. A shared team owning all BFFs recreates the same coordination overhead that the BFF model was intended to eliminate. The integration team’s role is to own the domain services and the infrastructure the BFFs run on, not the BFFs themselves. This requires the channel teams to have engineers capable of owning a server-side service, not just a mobile client or a browser application. If the mobile team does not currently have that capability, that is a hiring or training decision that precedes the BFF decision.
BFF SLA budget and circuit breaking policy. Each BFF has a response time SLA that is agreed with the channel team and encoded in the service’s alerting configuration. When a downstream domain service degrades, the BFF’s circuit breaker must determine how to respond — fail-fast if the degraded service provides mandatory data, or return a partial result if the data is optional. The definition of which fields are mandatory and which are optional for each channel is a business decision, not a technical one. It determines the customer experience during a downstream outage. Leadership must approve this definition before it is encoded in circuit breaker configuration, because a circuit breaker policy that fails-fast on an optional service takes a channel entirely offline unnecessarily, while one that degrades-silently on a mandatory service returns a misleading partial result.
Governance of cross-cutting concerns. When the bank needs to add a new cross-cutting capability — a new consent scope mandated by a SAMA Open Banking update, a new field required by a regulatory reporting obligation — it must be propagated across all BFFs consistently. Without a governance process, the open banking BFF gets the update but the mobile BFF does not, and the mobile channel inadvertently exposes data that should be gated by the new consent scope. The governance process for cross-cutting updates is lightweight — an architecture decision record published to all channel teams, with a compliance deadline — but it must exist and it must be enforced. The alternative is discovered inconsistency during a SAMA examination, which is the wrong time to discover it.
For the engineering depth behind these decisions — IBM ACE Fan-Out/Fan-In configuration, Spring Boot CompletableFuture composition with Resilience4j circuit breakers, timeout budget allocation, FAPI 2.0 scope filtering implementation, and the production checklist — see the companion Lab article: Integration Patterns: API Composition & Backend-for-Frontend.