Zhuifeng Notes

Bio

Mon, 01 Jan 0001 00:00:00 +0000

Who I am

Wang Peng. BSc in Mathematics, MSc in Computer Science. Backend architect at a bank’s headquarters (Beijing).

Day to day I work on the Enterprise Customer Information Facility (ECIF), core banking, and distributed systems. Familiar with:

database sharding, RocketMQ account-change notifications;
accounts / cards / payment settlement / interest / limits;
data governance and security encryption;
payment systems (China’s second-generation payment system, UnionPay / NetsUnion);
AML / KYC / CRS.

What I’m doing

Goal: grow from a bank technical expert toward CIO;
building a personal brand on the side — the WeChat column 金融科技百分百 (Fintech 100%) — writing on banking systems, fintech, payments, distributed systems, and IT architecture;
this site (Zhuifeng Notes) is where I consolidate technical columns, blog, and docs.

Writing & Columns

Mon, 01 Jan 0001 00:00:00 +0000

On this site I write three kinds of columns, matching different focuses of my banking work:

Architecture: ECIF, core banking, distributed architecture, and DDD;
Banking: payment clearing, interest and limits, accounts/cards, AML/KYC/CRS;
Data: data governance, encryption and security, sharding, messaging and stream processing.

I also run the WeChat column 金融科技百分百 (Fintech 100%), sharing hands-on practice and thoughts on banking systems, fintech, payments, distributed systems, and IT architecture.

Contact

Mon, 01 Jan 0001 00:00:00 +0000

WeChat column: 金融科技百分百
Email: (to be added)

First post — why "Zhuifeng Notes"

Sat, 15 Aug 2026 00:00:00 +0000

After years of building banking system architecture, most of what I’ve learned — the pitfalls, the hard-won insights — lived scattered across notes and chat logs. This site is where I organize them.

What I’ll write

Architecture: ECIF, core banking, distributed architecture, and how Domain-Driven Design (DDD) lands in banking.
Banking: payment clearing, interest and limits, accounts/cards, AML/KYC/CRS.
Data: data governance, encryption and security, sharding, messaging and stream processing.

Who it’s for

Peers, engineers moving into fintech, and anyone curious about why banking systems are designed the way they are.

Applying DDD Aggregates in a Banking ECIF

Wed, 12 Aug 2026 00:00:00 +0000

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.

ECIF in one read — why customer data must be centralized

Mon, 10 Aug 2026 00:00:00 +0000

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.

Bank Data Governance — metadata before quality

Sat, 08 Aug 2026 00:00:00 +0000

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.