Skip to content
Platform · Regulatory

Obligation library

Regulations arrive as prose, and your controls need something concrete to attach to. The obligation library breaks each framework, including BCBS 239, SOX, CCAR, GDPR, and the EU AI Act, into discrete obligations. When an examiner asks how you meet a requirement, you point to the obligation, the control behind it, and the data behind that.

What you get01 / 03
01

Pre-built obligation packs cover the frameworks banks actually face. Each framework is decomposed into obligations you can map controls to, not chapter summaries you can only cite.

02

Your own obligations sit alongside the pre-built ones. House policy, supervisory letters, and local rules are versioned and governed the same way.

03

Your existing compliance matrix imports as claims and is reconciled against the live control mappings, so inherited coverage is checked rather than assumed.

04

Every obligation shows its mapped controls, and an obligation with none reads as a gap on the board. Absence is failure, so nothing looks covered by default.

05

When a regulation is updated, the obligation is versioned and every control mapped to it is flagged for review, and the review itself is sealed on the ledger.

06

Coverage rolls up by framework and principle, so your second line can see which parts of BCBS 239 have controls behind them and which are still assertions.

How it works02 / 03
1

Load

Start from the pre-built packs for your frameworks and import your existing compliance matrix. It lands as claims to be checked, never as settled truth.

2

Decompose

Each regulation is broken into discrete, versioned obligations that a control can actually attach to.

3

Map

Controls attach to obligations through the one decision door: each mapping is proposed, reviewed by someone else, and sealed.

4

Watch

Coverage is derived from the live mappings, so an unmapped obligation or a stale mapping surfaces on its own.

Questions it answers03 / 03

“Which BCBS 239 principles do we actually have controls behind?”

Coverage rolls up by framework and principle, so your second line sees exactly which parts of BCBS 239 have mapped controls and which are still assertions. An obligation with no control reads as a named gap, not as silence.

“The regulation changed. Which of our controls need review?”

When a regulation is updated, the affected obligation is versioned and every control mapped to it is flagged for review. The review itself is sealed on the ledger, so you can show that it happened.

“Where is our coverage thin, before the examiner finds it for us?”

Every obligation shows its mapped controls, and one with none surfaces as a gap on the board. Because coverage is derived from the live mappings, thin spots appear on their own rather than waiting for an exam to expose them.

The next step

Start with proof, not a promise.

There are three ways in, and each one earns the next. You approve the exit criteria before we spend any more of your time or budget.

01

A 60-minute working session

Bring one report that is expensive to prove. We walk the mechanism against it. Nothing is required from your side.

02

A two-week guided sandbox

Your team works hands-on against a synthetic sample bank. It requires zero access to your systems and zero procurement.

03

A six-week proof on your systems

We use read-only metadata across five systems and one priority report, scored against criteria both sides sign first. The decision it produces is yours.