How Conway's Law Ruins OAuth/FAPI in Banks

Conway's Law https://en.wikipedia.org/wiki/Conway%27s_law is on full display in bank identity programmes. The organisational chart dictates the architecture, so OAuth and FAPI end up bolted together by committees rather than delivered by accountable teams.

I have watched this pattern repeat across the UK, Canada, and Brazil. No matter the market, silos trump protocol design, and the result is the same: expensive, fragile identity stacks that never quite pass conformance.

1. Auth Is Buried in the Wrong Place

Banks typically run identity work through a maze of teams:

• A security tools team
• An IAM or directory services team
• A DevOps or platform engineering team
• Product verticals such as cards, payments, SME, retail, or wealth

OAuth and FAPI do not belong neatly to any of them, so the work gets pushed into whichever group shouts loudest. Usually it lands with infrastructure security, so protocols are treated as plumbing rather than product-critical guardrails. FAPI becomes a checkbox, OAuth becomes a ticket queue, and nobody owns correctness. Identity architecture ends up downstream of politics, which is why banks keep shipping monstrosities that merely resemble OAuth.

2. Team Boundaries Become Protocol Failures

Split ownership multiplies hand-offs. IAM guards directories, the API gateway team controls traffic, security owns certificates, and retail owns customer login. A "simple" OAuth flow now looks like:

Browser → API Gateway → Retail Team → IAM Team → Security Team → Analytics → Back Again

That is OAuth by committee, and committees produce Frankenstein flows. Every lateral move introduces a bespoke tweak, and suddenly the protocol no longer matches the specification you thought you implemented.

3. Split Ownership Means Nobody Owns FAPI

FAPI is unforgiving. It demands tight discipline over PKI, metadata, client onboarding, and authorisation server behaviour. In a siloed bank, each of those areas is handled by a different team, so nobody feels accountable for the protocol end to end.

• Strict PKI discipline
• Strict metadata discipline
• Strict client registration discipline
• Strict authorisation server behaviour

Fragmented ownership guarantees slow, expensive remediation. "Our FAPI implementation does not pass the conformance suite and we cannot tell who to fix" is a sentence I have heard in at least eight banks.

4. Nobody Has the Authority to Say "No, That Is Not OAuth"

OAuth and FAPI collapse when teams deviate "just a little". Yet banks routinely compromise to avoid political friction. UX, compliance, legal, legacy systems, and vendor platforms all push local requirements that dilute the protocol. Without a strong identity owner, the organisation prioritises alignment over accuracy, so specifications bend until they snap.

The outcome is predictable: flows that look enterprise-grade on PowerPoint but fail fundamental OAuth checks in production. Vendor platforms that are 20% wrong slide through because nobody has the mandate to reject them.

5. Vendor Choices Mirror Org Shape

Vendor selection often reflects turf wars. IAM prefers Ping, security wants ForgeRock, the API platform installs WSO2, and the digital team experiments with Cloudentity. Each team optimises for its control surface, so critical protocol behaviour spreads across incompatible stacks.

That is how you get PKCE scripts running inside an API gateway, mTLS glued together by DevOps engineers who have never touched OAuth metadata, manual DCR because automation is "risky", or backend teams literally rewriting tokens. Architecture becomes a mirror of team egos rather than a coherent security model.

6. Cross-Functional Problems Have No Home

OAuth and FAPI problems are inherently cross-cutting: certificate rotations, client onboarding, metadata publication, trust framework compliance, PAR and JARM behaviour, ecosystem change management. No single department is structured to own that surface area, so gaps fall between silos until something breaks.

The result is firefighting. That is when I get the phone call. The bank frames it as a technical fire, but every time it is a Conway problem wearing an OAuth badge - and me and my team are parachuted in to "fix OAuth".

7. OAuth Becomes a Slow, Expensive, High-Drama Project

When identity mirrors the org chart, the bank defaults to large ceremonies, cross-team alignment sessions, and endless documentation. PowerPoint flows contradict production systems, API gateways pretend to be authorisation servers, PKI teams block ecosystem change, dynamic client registration takes twelve weeks, and rogue services bypass the spec because "we needed to ship". None of that is technical destiny; it is sociological inertia.

Why ODC Exists: Break the Conway Curse

The fix is not more code. It is a single accountable architecture, a unified identity narrative, cross-team governance, and a quarterback who can orchestrate every moving part. Designers and developers need to share one mental model, and protocol owners need authority to say "no" when the spec is at risk.

That is ODC's differentiator. We repair your OAuth by repairing the organisation that builds it. Once the teams align, the right code finally has permission to exist.

We fix your OAuth not by changing your code, but by fixing your organisation so the right code can exist.