---
title: "BIAN as a Contract Layer: Modernizing Core Banking One Domain at a Time"
description: "BIAN gives banks a shared vocabulary and service-domain contracts that sit between business concepts and the systems implementing them. See how domains, contracts, and governed access stack into one architecture."
---

# BIAN as a Contract Layer: Modernizing Core Banking One Domain at a Time

**Type:** [Architecture](https://yomu.fyi/visual-explainers/category/architecture.md)

![Layered architecture diagram showing banking business concepts above BIAN service-domain contracts, implementations below, and a side rail for governed access and domain-by-domain rollout.](https://yomufyi.s3.us-east-1.amazonaws.com/visual-explainers/b3c38543-0fb0-4f68-aa9d-eef8b1816a87/image-74a294ee-ec4c-4abc-a71a-d8fe3c0dfbb9.webp)

> BIAN gives banks a shared vocabulary and service-domain contracts that sit between business concepts and the systems implementing them. See how domains, contracts, and governed access stack into one architecture.

## Explanation

BIAN is a shared semantic foundation for banking: it names the domains a bank runs on, draws their boundaries, and defines the service operations they expose to each other. The architecture stacks business concepts on top, service contracts in the middle, and whatever implements each domain underneath, so a domain can be replaced without rewriting its neighbours. Because the contract is the stable layer, teams can modernize domain by domain instead of attempting one cutover. The cost is upfront semantic mapping and ongoing governance over who may call which operation, on whose behalf.

## FAQ

### Does adopting BIAN mean replacing my core banking system?

No. BIAN supplies a shared vocabulary and service-domain contracts, not a runtime. The BIAN and MongoDB perspective describes modernizing domain by domain, where each domain can keep or replace its implementation while the contract stays stable, so you avoid one risky cutover.

### Where does BIAN sit relative to my data store and existing integrations?

BIAN sits above the implementation layer: contracts define what a domain offers, while the store underneath can be a document model, a legacy system, or a federated source. The same post notes that JSON can serve as both storage and interchange format, which removes the ORM impedance mismatch when mapping domain objects.

### What is the main cost or failure mode when adopting BIAN?

The upfront cost is semantic mapping: agreeing what each domain means and where its boundary sits, because the same banking concepts are defined differently across systems today. The ongoing cost is governance over which caller may invoke which service operation, and skipping it reintroduces the duplicated logic and fragile integrations BIAN exists to remove.

**Tags:** [Architecture](https://yomu.fyi/topic/architecture.md), [BIAN](https://yomu.fyi/topic/bian.md), [Core Banking](https://yomu.fyi/topic/core-banking.md), [Integration](https://yomu.fyi/topic/integration.md), [Microservices](https://yomu.fyi/topic/microservices.md), [Modernization](https://yomu.fyi/topic/modernization.md)

## Related reading

### [Announcing Workday Data Connect federation in Unity Catalog](https://yomu.fyi/post/announcing-workday-data-connect-federation-in-unity-catalog.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Dan Zuckerberg, John Spencer, Kosta Bizetic, Katie Cummiskey
- Published: Oct 8, 2026
- Type: Announcement

Databricks announced the public beta of a Workday Data Connect federation connector for Unity Catalog, enabling zero-copy queries of Workday HR and finance data directly from the Databricks Data and AI Platform without ingestion pipelines. Workday shares tables via an Iceberg REST catalog; Databricks creates a foreign catalog in Unity Catalog and reads data from Workday’s managed object storage, with Unity Catalog governing read-only access through table-level permissions, lineage, and auditing. Teams can query the federated data using Databricks SQL, AI/BI, notebooks, or Genie for natural-language questions about workforce and financial trends. The connector requires Databricks Runtime 19 or above and a workspace admin to enable it from the Previews page. The release builds on the Databricks-Workday partnership announced at Workday Rising 2025 and complements existing Lakeflow Connect and Live Data Query options.


### [How to Repoint dbt ETL Pipelines to Databricks](https://yomu.fyi/post/how-to-repoint-dbt-etl-pipelines-to-databricks.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Khagay Nagdimov, Ismail Makhlouf, Shweta Verma
- Published: Oct 7, 2026
- Type: Tutorial

Repointing a dbt project to Databricks involves swapping the adapter and profile, handling SQL dialect differences, and keeping transformation logic unchanged. The dbt-databricks adapter bridges the project to Databricks Lakehouse, which uses a three-level namespace (catalog.schema.table) and supports open formats like Delta Lake and Apache Iceberg. Common dialect gaps include REGEXP\_SUBSTR, DIV0, and OBJECT\_CONSTRUCT, which can be fixed with Databricks-native functions or dbt\_utils macros; the post walks through each error and its fix. After compilation and validation using audit-helper to compare outputs model by model, the project can be deployed as a dbt task in Lakeflow Jobs with built-in governance via Unity Catalog. The process is incremental: one-time setup costs apply, then each additional model requires only dialect fixes, making it a low-risk starting point for warehouse migration.


### [Part 1: Make your AI agents boring: the determinism layer](https://yomu.fyi/post/part-1-make-your-ai-agents-boring-the-determinism-layer.md)
- Company: [Stack Overflow](https://yomu.fyi/company/stack-overflow.md)
- Author: Varun Jindal
- Published: Oct 7, 2026
- Type: Tutorial

The post introduces Level 1 of a six-level maturity model for production LLM systems, the determinism layer, which contains the model to a single node so the surrounding system is ordinary, testable code. The core design move is making the agent a pure function that proposes decisions without side effects, with a separate substrate that applies proposals only after approval. The system uses a fixed graph of nodes where the LLM is used only in one node for judgment, and all other nodes are deterministic, testable code. Structured output is enforced via schema constraints and validation, and confidence is composed from independent signals rather than taken from the model. For capabilities requiring autonomy, a bounded loop with a step cap and tool allow-list is used, but the default is the fixed graph to maintain predictability and auditability.


### [Now GA: Building permission-aware Databricks Apps with on-behalf-of-user authorization](https://yomu.fyi/post/now-ga-building-permission-aware-databricks-apps-with-on-behalf-of-use.md)
- Company: [Databricks](https://yomu.fyi/company/databricks.md)
- Author: Aakrati Talati, Cynthya Peranandam, Tushar Madan, Evan Pandya, Theo Fernandez
- Published: Oct 7, 2026
- Type: Announcement

Databricks Apps now generally supports on-behalf-of-user (OBO) authorization, enabling apps to act using the signed-in user’s identity so Unity Catalog enforces existing data permissions including row filters and column masks. Developers choose between app authorization for app-owned operations and user authorization for user-specific data access, with API scopes such as sql:restricted-query limiting what the app can do on the user’s behalf. The forwarded user access token is short-lived and per-request, passed via the x-forwarded-access-token HTTP header to the SQL connector, and the app must never store it. Workspace administrators can set an allowlist of API scopes, providing two levels of control: the app declares minimum scopes and the workspace defines the maximum, with account administrators able to add scopes outside the allowlist. The post recommends keeping app-owned and user-authorized clients separate in code and failing closed when a user token is missing to avoid returning results with incorrect permissions.


### [Data-Driven, Interoperable Core Banking: A BIAN and MongoDB Perspective](https://yomu.fyi/post/data-driven-interoperable-core-banking-a-bian-and-mongodb-perspective.md)
- Company: [MongoDB](https://yomu.fyi/company/mongodb.md)
- Published: Oct 6, 2026
- Type: Explainer

Core banking modernization is hindered by semantic fragmentation, where the same banking concepts are defined differently across systems, creating duplicated logic and fragile integrations. The Banking Industry Architecture Network (BIAN) provides a shared semantic foundation by defining common banking domains, boundaries, and service interactions, enabling a composable architecture. MongoDB’s document model, using JSON as both storage and interchange format, allows banks to represent business domains flexibly and evolve incrementally without schema migrations, eliminating the ORM impedance mismatch. MongoDB ensures financial integrity through single-document atomicity for common ledger updates and multi-document ACID transactions for complex cross-domain workflows, while Change Streams enable event-driven operations. Together, BIAN and MongoDB create an operating model for continuous transformation, where teams modernize domain by domain, supported by a shared business language and a scalable, flexible data platform.