There is one architectural decision in Open Banking Phase 2 that determines more downstream outcomes than any other, and it is made — or more often, deferred — at the executive level. That decision is whether to build consent management as a platform capability or as a Phase 2 implementation. The distinction sounds technical. The consequences are strategic and commercial, and they compound over time.
A consent platform is a shared service: it stores, enforces, and audits consent across every API product the bank exposes — open banking, third-party partnerships, internal service integrations. A Phase 2 implementation is a consent mechanism built specifically to satisfy the SAMA payment initiation specification, owned by the team delivering Phase 2, operated as part of the open banking programme. Both options produce working software. Only one produces a capability the bank can build on.
The technical team cannot make this choice. They can build either thing. The choice of which thing to build is made by whoever decides what kind of platform this bank intends to run — and whether open banking is a regulatory obligation or a product foundation.
What the regulator is actually checking
SAMA’s audit focus in Open Banking is not primarily the technology. It is the evidence. The regulator wants to know that for any customer dispute — “I did not authorise that TPP to read my transactions”, “I revoked that consent and the calls continued” — the bank can produce a complete, tamper-evident record of every consent lifecycle event, the authentication ceremony that created it, and the API calls made under it.
What that means technically: consent events must be immutable once written, timestamped to a precision that resolves disputes, and retained for ten years. The current consent status is a projection of that event log, not the source of truth. A bank whose consent implementation writes a status column in a relational table and updates it on revocation will fail that audit requirement — not because the system is wrong, but because it cannot produce the reconstruction the regulator needs.
This is a leadership decision about data architecture. The engineers who built Phase 1 consent knew what the right answer was. The question is whether the programme gave them the time and authority to build it, or whether they shipped what could be shipped before the deadline.
The trade-off the business has to make
The centralised consent platform costs more to build and takes longer. The Phase 2 implementation costs less and is faster. That trade-off is real and the leadership team should not pretend it isn’t. The question is not whether the trade-off exists; it is which horizon to optimise for.
If the bank’s open banking ambition ends at regulatory compliance — expose the mandated APIs, maintain them, nothing more — the Phase 2 implementation is probably the right call. The additional cost of a platform capability will not be recovered by the revenue it enables, because the revenue strategy doesn’t require it.
If the bank intends to use open banking as a distribution channel for premium API products — transaction enrichment, merchant analytics, embedded finance primitives, real-time risk scoring sold to fintech partners — then the Phase 2 implementation will be rebuilt within two years. Every premium API product requires consent to operate. If each product brings its own consent mechanism, the bank ends up with multiple consent stores, multiple audit trails, and a customer experience where “managing my connected apps” requires navigating multiple bank systems. That is not a commercial-grade platform. That is Phase 2 repeated several times with increasing coordination cost each time.
What the team needs from leadership to build it right
The engineering teams delivering Phase 2 can build the consent platform, if they are given three things that programmes typically do not give them.
A product owner, not a programme manager. Consent management is a product. It has a customer — the TPP ecosystem and the bank’s own product teams — and it has a roadmap: CIBA flows, partial consent revision, consent delegation, event notifications, audit API. A programme manager ensures delivery against a specification. A product owner makes decisions about scope, prioritises the roadmap beyond the initial go-live, and owns the capability after the programme closes. If consent management does not have a product owner, it will not have a roadmap, and the roadmap is where the platform value lives.
Architectural authority over the token and identity layer. Consent management touches everything that issues or validates tokens: the authorization server, the API gateway, the resource APIs, the fraud system. In a typical programme structure, these systems are owned by different teams with different delivery managers and different priorities. The consent platform team needs to be able to make changes to all of them, or to specify those changes and have them prioritised. Without that authority, the team will build a consent service that is structurally isolated from the systems it needs to influence, and the result will be the stateless-validation architecture that fails at revocation propagation.
Time after go-live. The consent platform as delivered on Phase 2 go-live will not be complete. The first twelve months of production operation will surface the gaps: edge cases in the consent lifecycle, TPP integration patterns that weren’t anticipated, SAMA guidance that arrived after the design was locked. The team needs runway to address those gaps without the intensity of a compliance deadline. This is the investment that separates a platform from a delivery that is declared complete and quietly degraded.
The question that determines the answer
The consent platform decision resolves to a single question that the leadership team has to answer honestly: what is open banking for?
If it is a regulatory obligation the bank must satisfy at minimum cost, the implementation approach is correct and the trade-off is well understood. If it is a platform through which the bank intends to compete in the open banking era — building ecosystem relationships, offering premium API products, attracting fintech partners who will choose which bank’s infrastructure to build on — then consent management is a core product capability, and the cost of building it properly is a fraction of the cost of rebuilding it once the commercial ambition outgrows the Phase 2 implementation.
That is not a technical question. It is a strategic one. And it needs to be answered before the Phase 2 architecture is locked, not after it is in production.