How to Read the Org — Modupay Labs

Domain: A top-level grouping — Foundation · Enterprise AI & Automation · Digital Banking & Processing VAS · Money Movement & Financial · Ecosystem & Bespoke. Reads across the top.
Business line: A box inside a domain (e.g. Retail, Enterprise AI, Ecosystem). The unit with its own market and, where relevant, its own P&L.
Product: A product or app a business line ships — shown as tags inside each line box (e.g. Retail: Banking App · Card App · AI PFM). One line can carry several.
Chapter: A craft function shared down every column — Growth · Discovery · Engineering · Delivery. People belong to a chapter (their craft) and serve a line.
Cell / seat: A chapter × business-line intersection — the actual work that craft does for that line.
Business Ops: The cross-cutting corner team. Serves every domain and chapter.

Colour: One hue per domain — slate = Foundation, blue = Enterprise AI & Automation, purple = Digital Banking, teal = Money Movement, amber = Ecosystem & Bespoke.
Weight: deep tint + thick bar = domain header · soft tint + thin bar = business line · faded + left accent = a craft seat.
Faded column: Planned but not yet staffed (currently Non-Banking Financial and Bespoke).

Why it’s built this way

Digital Banking vs Retail — what's the difference?

Domain = the technology. Business line = the market.

Digital Banking is the shared platform (the "what"). Retail / Merchant / Corporate are the audiences it serves (the "who"). One platform, filtered by audience — "build by function, filter by audience, sell by value."

Foundation owns the reusable core; the segment lines only configure it — they never own their own stack. That org boundary is what prevents three divergent codebases.

Why is Business Ops in the corner?

It's cross-cutting — it sits at the origin, not inside a domain.

Business Ops (P&L, pipeline, coordination, admin) serves every domain across and every chapter down. Placing it at the (0,0) corner shows it belongs to the whole matrix, not one column.

Why merge Delivery and Reliability?

One chapter — Delivery — spanning go-live and run/SRE.

At our scale, two chapters would each be sub-scale. Ship and operate are the same half of the lifecycle, and merging removes the go-live→run handoff where balls get dropped.

Reliability survives as a named SRE track inside Delivery, owning the uptime SLOs — the same "quality veto" pattern Engineering uses — so the stability voice isn't drowned by go-live pressure. Re-split when the SRE track alone needs a full on-call rotation.

Where does integration work live?

Split by commodity-vs-specialized, and inbound-vs-outbound.

Foundation owns the standard + commodity pipes (SDK packaging framework, reusable connectors: SMS, push, KYC). Ecosystem & Bespoke owns specialized integrations (third-party scheme SDKs like Visa VFC, partner SDKs, one-off client work) — built to Foundation's standard. Each business line owns its own line-specific SDK/offering.

The need often surfaces from a line (e.g. SMS for the Retail app), but the owner is Foundation if it's reusable — trigger ≠ owner. That's what keeps "same technology" true across every line.

Why is AI its own domain?

Enterprise AI & Automation — two lines: Workflow Automation + Enterprise AI.

Workflow Automation is measured on cost saved; Enterprise AI on revenue earned. One talent home, two missions. Scorecard = revenue + savings − cost. (Financial-product AI & dashboards live in Data & Intelligence, not here.)

The same scarce ML/MLOps people serve both, so they share one home (standards, tooling, hiring). Keeping the missions as separate lines protects two different scorecards — and builds in the internal→external path: automation proven on our own ops graduates into bespoke bank automation.

Rejected: merging the two into one box — it re-buries Enterprise AI (which we deliberately surfaced) and muddies the per-line P&L.

Two bosses — who's actually accountable?

Accountability follows the outcome — one name per result.

Reporting lines are about people; accountability is about results. Every outcome has exactly one accountable owner.

Result	Accountable
The outcome — shipped, works, sells	Business line
Built well — quality, safety, scale	Engineering
On time / as promised	Delivery
Priority tie-break	Product