Capability 02 — Merchant management
Control
Most compliance tooling reads the record after the money has moved. Control is the part that runs first — merchant, buyer, product, geography and transaction evaluated against the institution's rules before a request is submitted at all.
Policy management
The institution's rules as data, versioned on publish, with every decision bound to the version in force.
Access controls
Permissions resolved on institution, organization and role at the row level, not at the screen.
Workflow automation
The same sequence every time, from every channel, so a submission cannot take a shorter route.
Regulatory alignment
Rules written from counsel's control matrix, with the position each rest on documented and attributed.
Reporting and governance
Portfolio, intervention and exception reporting generated from the record rather than a second copy of it.
The order is deliberate
Evaluation runs platform, then merchant, then product, then order, then buyer, then portfolio. Halts sit at the front, which means a suspended merchant with lapsed documentation stops at the halt and the documentation check never runs.
Putting the most absolute stop first is not an optimisation. It means a halted program cannot be reasoned past by anything downstream of it — no product, no buyer, no order value gets to re-open a decision the institution already made.
The rail set is frozen at the decision
A decision does not return permission in the abstract. It returns the specific set of rails eligible for that merchant, that product and that buyer at that moment, and checkout may present only those. A rail excluded because one item in the order restricts it stays excluded for the whole order.
Freezing the set is what stops a retry from quietly widening it. Without that, a buyer who fails on one rail simply tries another until something clears, and the control becomes advisory.
Blocked is not declined
A compliance block and a payment decline are different events. They have different causes, different records, different buyer messages and different screens, and they are never merged into one list with a status column.
A decline is financial and retryable. A block is terminal — no retry, no alternate rail, no path back into payment. Collapsing them is how a compliance stop gets quietly treated as a technical hiccup and retried until it works.
The buyer is not told which rule stopped them
A blocked buyer sees one sentence and a reference. Which of the rules fired is for the merchant's console and the audit trail, not for someone who might be probing to find the edge of the ruleset. The reference is what makes the block explicable to anyone with a legitimate reason to ask.
What control does not do
A control layer is only useful to an institution if its limits are as clear as its capabilities.
Card entry is hosted fields served by the acquirer's gateway. Nothing in the schema can represent a card number.
Control decides eligibility. Settlement is between the processor, the acquirer and the merchant.
Absence of a rule is never permission. A geography or buyer requirement nobody set fails closed.
See it running
Control runs in the control plane alongside the other three capabilities, on representative data.
Or start a pilot conversationThirty-three screens. Nothing in it is a real merchant or a real transaction.