A bank decides to use the BIAN Service Landscape to redesign its core-banking service boundaries, but the standard defines far more Service Domains than the bank could ever implement. Walk through the practical process for scoping and constraining a reference architecture like this to one organization.

## The exercise, and its three buckets Scoping a reference architecture like BIAN's Service Landscape to one organization is fundamentally a **capability-mapping exercise**, not a subset-selection checkbox. It starts with an honest inventory of the organization's actual business capabilities and the systems that currently deliver them — typically produced via workshops with both business capability owners and the architects who know the legacy estate. That inventory is then compared, Service Domain by Service Domain, against BIAN's roughly 300-plus domains (Party Reference Data Management, Current Account, Credit Card Authorization, and so on), and each comparison is sorted into one of three buckets. | Bucket | What lands in it | |---|---| | **'Adopt as-is'** | domains where the bank's actual business capability matches the standard's definition closely enough that no local adaptation is needed | | **'Adopt with adaptation'** | domains where the underlying capability is real and mapped, but the boundary needs to be renamed, split, or merged to reflect a genuine local difference — for example, splitting BIAN's generic Current Account domain into separate retail and SME variants because the two have materially different regulatory reporting obligations | | **'Out of scope'** | parts of the standard the organization simply doesn't need, either because it doesn't offer that product line or because a legacy system covering it is being retired rather than re-platformed toward the standard | ## The delta document, not the pristine model The output of this exercise is not the raw BIAN model — it is a **delta document**, an annotated overlay showing exactly where the organization matches, deviates from, and ignores the reference. This delta becomes the organization's real target architecture. Treating the annotated delta, rather than the pristine standard, as the thing teams build against is the single most important discipline in the whole process, because it is the only version of the map that reflects genuine organizational reality. ## Three forces constrain the mapping Three forces constrain how that mapping gets drawn. 1. **First, regulatory obligation.** A domain boundary that regulators expect to see reported on separately effectively forces a split regardless of what the generic standard assumes. 2. **Second, legacy system reality.** A bank cannot decompose a forty-year-old mainframe core-banking system into clean BIAN Service Domain boundaries overnight, so the mapping has to acknowledge an interim state — a coarse-grained legacy system standing in for several target domains at once — with a migration roadmap toward the finer target boundaries. 3. **Third, genuine standard gaps.** Some organization-specific capabilities, such as a proprietary fraud-scoring model or a regionally unique product, simply have no clean home in the reference model and are deliberately left outside it rather than forced in. ## Owner, cadence, and phasing This scoping exercise is not a one-time event; it needs an owner and a recurring review cadence, or it decays. A common and sound practice is to run the mapping as a scoped exercise tied to a specific transformation program rather than attempting to map the entire enterprise up front — a bank might deliberately map only the twelve or so Service Domains relevant to a new digital lending program in the first phase, explicitly deferring the other 280-plus domains as out of scope for now, and expanding coverage as later programs are funded. This phased approach avoids the failure mode where an enterprise architecture team spends a year producing a comprehensive but unenforced wall chart while no actual delivery happens against it. ## Enforcement, not just documentation Because the delta document is meant to be the living target, it needs enforcement, not just documentation. A lightweight architecture review checkpoint — for instance, at each sprint boundary or release gate — comparing newly built APIs against the documented mapping catches drift early. Without this, teams under delivery pressure will pragmatically build whatever is fastest, and the map silently stops reflecting what was actually shipped, eroding exactly the shared-vocabulary and audit value that motivated adopting BIAN in the first place. ## The same discipline in telecom The identical discipline applies to TM Forum's frameworks in telecom: an operator does not implement every `eTOM` process or every `SID` entity, it - maps its relevant end-to-end processes and information entities onto the subset that matches its actual product and operations model, - documents local extensions where products don't fit the generic shape, - governs that mapping the same way. ## Putting it together A concrete illustration: a bank's digital lending program maps twelve Service Domains for its initial scope, splits Party Reference Data Management into two services because of a jurisdiction-specific KYC data residency law, and adds a sprint-boundary architecture checkpoint. Two sprints in, that checkpoint catches a team that had started building loan-servicing endpoints directly against the core ledger, bypassing the intended Consumer Loan Fulfillment domain boundary — a divergence that, left unnoticed for the rest of the program, would have eroded the very service isolation the mapping exercise was meant to establish.