MARSAD
Methodology/ Capability map

What banking capabilities does this bank operate, and what underpins each one?

The IBS register is the bottom-up inventory. The capability map is the top-down lens that puts each service back in the banking-domain frame the regulator already thinks in.

What it is

The Capability Map is a banking-domain reference grid: the BIAN service landscape, extended with the Saudi-market rails (mada, SADAD, SARIE, REDF, SIMAH, Nafath, Tanfeeth, and peers) that any KSA-licensed bank operates. The grid itself doesn’t change between deployments; what changes is the overlay each bank paints onto it.

Where the IBS register answers which services are critical? and service classification answers what about everything else?, the capability map answers the third question regulators ask: what banking capabilities does this bank actually operate, and which of them sit in MVB scope?

Why it matters

Lists of services are easy to assemble. Reading them against a banking-domain ontology is what tells the regulator the bank actually knows what it operates. Three audiences read the map differently:

The four data layers

Every cell composes four ingredients, each with its own single responsibility:

Reference scaffolds: the BIAN service landscape (19 zones, 544 tiles) and the Saudi-market capability map (11 zones, ~292 capabilities including the mada, SARIE and SADAD rails). Static; they don’t change per tenant. Implementation links: M:N edges from capabilities to the services and IBSes that implement them, plus capability-to-capability dependencies. Live overlay: MVB membership and the live cascade, lighting cells from the operational twin rather than from a hand-maintained status.

The split matters because it lets the bank work the layers independently. The scaffolds ship with the platform; the links populate through curation and import; the live overlay follows the estate on its own.

Status is derived, not declared

A cell’s state comes from the model rather than from a hand-assigned label. A capability with mapped services reads as operated; a capability linked to an MVB-flagged IBS carries the MVB mark; a capability downstream of a live incident lights up in the cascade lens, with the tracing line back to the cause. A cell with no links reads as unmapped reference, which is itself signal: it is the “have you considered every capability” question made visible.

This is deliberate. A declared status drifts the day after the workshop that set it; a derived status is only as stale as the register underneath it, and that register is what the rest of the platform keeps honest.

Three ways to populate the map

Wiring every capability to its services by hand is the longest pole in the tent for any capability-map exercise. MARSAD ships three complementary population pathways, and banks pick whichever matches the artefacts they already have:

MVB threads through the map

One of the map’s headline features is the Baseline ↔ MVB toggle. Flipping it dims every cell whose linked IBS is not in MVB scope on the active declaration, leaving only the capabilities the MVB protects under a dual-DC outage scenario.

The derivation is server-side and traces the same path the IBS-register MVB toggle does: a capability is MVB-linked iff any of its implementing IBS is in MVB scope on the active declaration. No hardcoded list of “MVB cells”: if the active declaration changes, the highlight updates with it.

The connection point. The capability map becomes a top-down lens onto the MVB methodology. Instead of asking which IBS are MVB?, the regulator can ask which banking capabilities does the MVB cover? and read the answer off the map directly.

How MARSAD frames it

The capability map sits one level above the three regulator- facing ledgers:

The capability map asks: given all of that, which banking capabilities does the bank operate, what underpins each one, and which capabilities are protected by the MVB? Every cell-click in the map traces back into the ledgers.

What customers see

Design note. The capability views ship with the Operational Twin module. Where a deployment enforces module licensing, the routes and navigation follow the licence; nothing renders as an empty view.

Related methodology