Feature catalogue

Countersign

Countersign is four-eyes approval over the actions a tenant chooses. A clerk captures the change; it does not take effect until the required approvers sign it. Nobody can approve their own capture.

What can be countersigned

Every mutating action in LedgerTM resolves to an action id — operations.give-notice, credit-limit.increase, and so on. That id is the unit approval rules key off, and it is the same id access control keys off, so one vocabulary covers both.

An action is eligible for countersign unless it is one the system runs on its own behalf (day-end, seeding, a cascade), or one of the countersign control actions themselves. Approving an approval would need its own approval, so those are excluded by construction.

Approval rules

A rule matches an action id, optionally narrowed by a predicate over the action’s own facts, and states the quorum it requires:

Part of the rule What it says
Action Which action this rule governs
Predicate An optional condition over the action’s facts, such as amount > 500000
Thresholds Per-currency amounts, so a limit means the same thing in each currency
Require The quorum: one or more groups, each with a count

A single require entry means “N approvals from this group” — the common case. Two or more entries express separation of duties: one from Credit Risk and one from Treasury, which no single team can satisfy alone.

Worked example

A tenant wants rate changes above half a percent of movement to need a second pair of eyes from Treasury, and everything else to go straight through.
Action operations.change-rate
Predicate spread > 0.5
Require 1 from Treasury

A clerk changes a rate by 0.25 — no rule matches, the change applies. A clerk changes a rate by 0.75 — the change is captured, a Treasury approver sees it in their queue, and the rate moves when they sign. If nobody signs, nothing happened: the account is untouched and the capture is on the record.

What the clerk and approver see

The captured change appears on the Staged Changes panel of whatever it affects, showing the full before-and-after the change carries. An approver sees the same list the clerk captured, not a summary of it, so the thing being approved is the thing that will run.

Every change shows the values it sets. A change that nobody wrote a tailored summary for still lists what it carries, field by field, so the panel is never empty for a change that is really there.

A capture that is never approved never takes effect. It stays visible as a capture, which is the audit answer to “who asked for this and who refused it”.

What the old value tells you

Each row shows the new value on the right. What appears on the left depends on what the system was able to record at the moment of capture.

On the left What it means
The old value The value being replaced was recorded when the change was captured.
prior value not captured Nothing recorded what this field held beforehand.
newly set (on the card) The change creates the record, so there was nothing to replace.

Prior value not captured is neither a warning nor a blank. It says the system did not record the old value, rather than claiming there was none. Read it as: you are approving this new value, and this screen cannot show you what it replaces. If you need the old value, open the record itself before you sign.

Newly set marks a card that creates something. That card stays on its own, and never merges with later changes to the same record.

Worked example

A clerk corrects a counterparty’s tax residency from the United Kingdom to South Africa. The approver opens Staged Changes and sees one card, Correct tax residency:

Field Old New
Country code GB ZA

The old country was recorded when the correction was captured, so the approver reads the change rather than only its result. Fields the correction leaves alone are not listed — the card shows what moves.

If the clerk captures a second correction to the same residency before anyone signs, the two appear as one card showing the latest value, labelled with how many captures it nets.

Changing your approval rules

The rules are the controls, so changing them is itself controlled. You edit them on the Approval Rules settings screen, which keeps your edits in a staged copy. Nothing you do there reaches the live rules until you publish the staged copy.

  1. Open the Approval Rules settings screen.
  2. Add, edit, or remove rules. Each change lands in the staged copy.
  3. Select Publish.

Publishing is an action like any other, so your organisation can require a second pair of eyes for it. Where it does, the live rules move only once an approver signs.

A change sent to the live rules without going through the staged copy is refused, and the refusal says the change has to be staged first. There is no way to edit the live rules in one step.

What your organisation configures