No industry has invested more in business architecture than financial services — and none shows more clearly both what the discipline delivers and where a reference model can quietly steer you wrong.

If business architecture has a home turf, it is financial services. Banks, insurers, and asset managers were among the earliest and heaviest adopters, and for reasons that make the industry a useful lens for everyone else. The forces that pushed financial services toward formal architecture — regulation, complexity, scale, and relentless change — exist everywhere; they are simply turned up to maximum here, which makes the consequences of getting architecture right or wrong unusually visible.

Why the industry leaned in

Four pressures did the pushing. Regulation demands that an institution be able to describe what it does and prove control over it — a capability map is, among other things, an answer to a regulator's questions. Complexity is extreme: a universal bank runs retail, commercial, markets, payments, wealth, and risk businesses that share customers, data, and systems in tangled ways no org chart captures. Scale means a small structural inefficiency multiplies across millions of transactions. And the pace of change — digital entrants, new rails, shifting rates — keeps reopening the question of whether the institution is still configured for the world it now operates in. Architecture is how large financial institutions keep answering that question without starting from scratch each time.

What an industry reference model buys you

Financial services is unusually well served by industry reference models — pre-built, standardized maps of the capabilities, value streams, and information a typical institution needs. Several mature ones are in wide use across banking and insurance. Their value is real and worth being specific about. They save months of inventing the obvious, since the top two levels of a bank's capability map are largely common across banks. They give a shared vocabulary, so "client onboarding" means roughly the same thing in two institutions and across vendors. They embed hard-won completeness, surfacing capabilities a homegrown effort would forget. And they let you benchmark, because a standard structure makes peer comparison possible at all.

Where reference models mislead

The same standardization that helps is where the trap is set. A reference model describes the industry, not your institution, and the difference is exactly where strategy lives. Three failure modes recur. Adopting it wholesale: importing all five levels because they exist, and drowning a real decision in a model no one will maintain — the same completeness-over-use mistake from Issue 2, now shipped in a box. Mistaking the map for differentiation: the reference model is, by design, what every competitor also has, so it tells you the table stakes, never the edge — your strategy is in how you weight, mature, and combine the standard capabilities, not in the standard list itself. And losing the local truth: the model's clean categories can paper over the genuinely unusual thing your institution does, which is often the thing that matters most.

How to use one well

The disciplined approach treats the reference model as a starting draft, not a destination. Take the top two levels as a head start on the boring, common trunk. Then do the work the model cannot do for you: prune to what your institution actually needs, rate the capabilities for maturity against your strategy, and pay particular attention to where your reality refuses to fit the standard boxes — because that misfit is usually information, not error. The reference model gets you to the starting line faster; it cannot run your race.

A worked example: where the model went quiet

A mid-tier bank adopted a well-known industry capability model and, for the most part, it worked exactly as advertised — the retail, payments, and lending domains mapped cleanly, the vocabulary aligned with its vendors, and months of inventing the obvious were saved. Then the bank tried to place the thing it was actually known for: a specialist trade-finance business serving a particular export corridor, the reason its largest clients banked there at all. The reference model had a tidy, generic "trade finance" box that flattened the very distinctions the bank competed on. The standard categories went quiet exactly where the strategy lived.

The team's instinct was to force their reality into the standard box so the map stayed "clean." The better move was the opposite: treat the misfit as the signal it was, and model that corner in the bank's own terms even though no peer's map would match. A reference model earns its keep on the common eighty percent precisely so you have the attention to spare for the twenty percent that is yours. The place it falls silent is usually the place that matters most.

Which reference models, and what they are not

Financial services is well supplied with these models, and it is worth knowing the landscape rather than treating "the reference model" as one thing. In banking, industry bodies and vendors maintain capability and process frameworks — BIAN's service landscape for banking architecture, cross-industry process classification frameworks such as APQC's, and the proprietary models the major advisory firms license. Insurance has its own lineage around standards bodies such as ACORD. They differ in altitude and intent: some describe capabilities, some processes, some data and messaging standards — and confusing one for another imports the wrong thing. A data-exchange standard is not a capability map; a process framework is not an operating model. Know what each is built to describe before you adopt its vocabulary wholesale.

Whatever the source, the same caution applies, and it is the through-line of this whole issue: a reference model is a description of the industry's commonality, maintained by people who have never seen your institution. That is precisely why it is useful for the shared eighty percent, and precisely why it is silent on the rest. Used as a first draft it is leverage; adopted as the finished map it quietly standardizes away the very things your strategy is built on. The discipline is to take the head start gratefully, then do the harder, local work the model was never able to do for you.

It is worth being precise about what "regulated" does to the work, because it is the force that most distinguishes financial-services architecture. Regulation turns the capability map from a planning aid into something closer to evidence: a regulator asking whether you control a given activity is, in effect, asking to see the capability — who owns it, and how it is governed. Institutions that already maintain an honest map answer in days; those that do not assemble one under deadline, badly. The discipline that looks like overhead in calm times becomes the cheapest insurance the organization owns the moment scrutiny arrives.

Why it generalizes

Everything financial services learned the expensive way applies wherever regulation, complexity, scale, or pace is rising — which, increasingly, is everywhere. Healthcare, energy, telecoms, and the public sector are walking the same path, and the lesson travels intact: a reference model is leverage on the common 80% so your scarce effort goes to the 20% that is actually yours. Use it for the head start, never for the strategy. That distinction — between what an industry shares and what a single organization must decide for itself — is a fitting place to pause the first volume of Span, because it is the distinction the whole discipline exists to manage.

Every regulated industry has a compliance tax — the percentage of architectural effort that goes toward demonstrating, rather than achieving, control. In some banks, it’s 40%.

The instinct is to minimize this tax. The wiser move is to architect for evidence from the start. Every control has two costs: the cost of implementing it, and the cost of proving it. The second is usually larger and is almost always underestimated.

If you design a system where logs are scattered, identity is federated across silos, and approvals live in email — your control might be perfect, but you’ll spend a fortune proving it every audit cycle. If you design with evidence in mind — centralized logging, structured approvals, identity that resolves cleanly — the same control costs a fraction to demonstrate.

Design for the auditor as carefully as you design for the user. The auditor is a user. Their workflow matters.

An industry reference model is a pre-built, standardized description of the capabilities, value streams, and information a typical organization in a given industry needs — for example, the widely-used banking and insurance capability models. It is a starting template grounded in how the industry generally operates.

Its value is leverage: the top levels of most organizations' capability maps within an industry are broadly similar, so a reference model saves months of inventing the obvious, supplies a shared vocabulary, and enables benchmarking against peers because everyone is using a comparable structure.

Its limit is that it describes the industry, not your organization. Because every competitor has access to the same model, it captures table stakes rather than differentiation — the strategy lives in how you prune, weight, and mature the standard capabilities, and especially in the places your reality does not fit the standard boxes. Use it as a first draft, never as the finished map.

A reference model so pristine,
Was the prettiest deck ever seen.
But it sat on a shelf,
Talking just to itself,
While the codebase grew wild and unclean.