Skip to content

Columns

Themed column series organized along the main work tracks.

Columns

Themed column series organized along the main work tracks.

Entry points to themed columns. Each column follows one main thread, with articles forming a long-term reference.

Contents

Architecture

Hands-on breakdowns of ECIF, core banking, distributed architecture, and DDD.

The complexity of banking systems rarely lives in a single technique — it lives in weaving regulation, accounting, channels, and performance constraints into one coherent fabric. This column breaks down the key decisions and trade-offs.

Articles in this column:

Applying DDD Aggregates in a Banking ECIF

Is a customer “one entity” or “a set of contexts”? Reslicing the ECIF customer model with aggregate roots and bounded contexts.

In an ECIF, the concept of “customer” is huge: retail, corporate, and interbank clients each have different attributes, relationships, and lifecycles. Forcing them into one giant Customer entity makes the code rot fast.

Slice by bounded context

Split the customer across bounded contexts:

  • Party (master data): unified natural-person / institution identity and base attributes.
  • Profile: risk appetite, marketing tags — high read/write churn.
  • Relationship: shareholding, guarantee, and group relationships.

Where the aggregate root goes

Each context defines its own aggregate root. In Party, Party is the root; Address and Contact are value objects, keeping cross-aggregate calls out of the consistency boundary.

Lesson: draw aggregate boundaries by transactional consistency, not by the size of the business concept. The most common ECIF mistake is stuffing all customer data into one aggregate.

With this design, the master-data service stays stable while the profile service iterates independently.

Banking

Payment clearing, interest and limits, accounts/cards, AML/KYC/CRS — core banking topics.

A bank’s business rules are where the real complexity lives. This column explains core banking from first principles, so technical decisions have a business basis.

Articles in this column:

ECIF in one read — why customer data must be centralized

From duplicate accounts to a unified customer view, ECIF answers banking’s most basic question: who is the customer?

Before ECIF, branches, internet banking, and the card center each kept their own customer records. The same person appeared with different names, IDs, and contacts across systems — making both marketing and risk control impossible.

What ECIF solves

ECIF (Enterprise Customer Information Facility) consolidates customer master data scattered across business systems into one place, exposing a single customer view.

  • Unique identity: a Party ID unifies natural persons / institutions, not the ID number.
  • Primary/secondary: supports one person many accounts, one account many cards, with unique master data.
  • Service-oriented: other systems query via interfaces instead of keeping their own copies.

Key technical trade-offs

  • Read/write split: master writes are strongly consistent; queries can hit cache / read replicas.
  • Auditable changes: customer changes are traced to satisfy regulatory audits.

ECIF is not “yet another database” — it is the bedrock of bank digitalization.

Data

Data governance, encryption and security, sharding, messaging and stream processing.

Data is both an asset and a risk for a modern bank. This column focuses on engineering practices that make data usable, trustworthy, and controllable.

Articles in this column:

Bank Data Governance — metadata before quality

Data governance is often reduced to form-filling; the real lever is metadata lineage and quality rules built into the pipeline.

Many bank data-governance programs degenerate into “fill in the metadata, assign owners.” To get results, governance must be built into the data production pipeline.

Do two things first

  • Metadata & lineage: where a field comes from, which jobs transform it, where it flows — must be tracked automatically.
  • Quality rules built-in: non-null, uniqueness, consistent definitions act as ETL/lakehouse gates; bad data never lands.

Security & encryption

  • Encryption at rest: sensitive fields (ID numbers, card numbers) encrypted on disk.
  • Dynamic masking: query-side masking by role; dev environments never see plaintext.

The goal of governance isn’t a pretty report — it’s giving downstream systems confidence to use the data.