Roles and authority

Escrow NEW puts two companies and Wolf around one record, so every screen has to answer “whose is this?” before it answers anything else. Authority there is a closed list of capabilities held by nine named seats, and a reviewer switches between them.

AML Officer 3.0 is one function’s workspace. There is no persona switcher and no capability gate on a control, because everybody who gets in belongs to the AML function. The separation that matters there is between the lines of defence, and it is carried on the command and enforced as an ordering rule on the work itself.

Both models are enforced in the same place: the reducer that writes the record. Neither relies on a screen being polite.

The switcher is the one control on these screens that belongs to the reviewer rather than to a seat, and its header states exactly what it does: view this transaction as, and the record does not change, only what this role may see and do. Each row carries the name, the register spelling of the seat and the same authority note printed above. The two client groups name the company they act for; the Wolf groups name none, because Wolf acts for neither company. Switching routes you to the new seat’s home, so nobody lands on a surface their seat cannot use.

Two properties are worth reading off the grid rather than out of a paragraph. First, no capability is held on both sides: 13 belong only to client seats and 19 only to Wolf. No Wolf seat can accept terms, raise a dispute or agree a cancellation, because Wolf never binds a client company; no client seat can read a Wolf-internal record, a compliance-restricted one, or export the audit trail.

Second, 16 of the 32 capabilities have exactly one holder, which is where the model actually bites. There is no second seat to fall back on and no escalation path in the interface:

• create_escrow: Wolf · Operations Maker
• configure_terms: Wolf · Operations Maker
• prepare_funding: Buyer · Finance
• allocate_balance: Buyer · Finance
• approve_fx_instruction: Buyer · Authorised Signatory
• execute_fx: Wolf · Operations Maker
• record_external_result: Wolf · Operations Maker
• approve_evidence: Wolf · Operations Maker
• request_correction: Wolf · Operations Maker
• request_release: Seller · Transaction User
• buyer_confirmation: Buyer · Authorised Signatory
• record_resolution: Wolf · Operations Maker
• apply_operational_hold: Wolf · Operations Maker
• reconcile_funding: Wolf · Operations Maker
• prepare_settlement: Wolf · Operations Maker
• extra_approval: Wolf · MLRO / Director

A tool shows you what you can do. An action belonging to another role is simply not there, the same way a buyer never sees an operator’s controls in the finished product. A wall of greyed-out buttons teaches a client that the product is full of things they cannot have, which is noise rather than information, and it makes every screen a worse read for the person who does hold the seat.

The same rule is applied one level up, at the container, so an empty card never appears either. Each caller works out the seat’s authority before it renders the section around the controls:

• Release: hasScopeActions tests prepare_settlement, raise_dispute and the resolution capability before the scope card is drawn at all.
• Approvals: showActions tests approve_movement, or extra_approval when the instruction requires it.
• Funding: the FX section appears only for a seat holding approve_fx_instruction or execute_fx.
• Activity: the export control is behind a plain can(persona, "export_audit") test.

The consequence for a reviewer is that a screen held by the wrong seat looks thin rather than locked. That is the intended reading. The authority model is documented here; it is not spelled out on every screen.

GatedAction takes an optional blockedReason, documented as a state-level block that applies even to a role holding the capability. When it is set the control stays on the screen, disabled, with a security icon and the reason printed underneath.

The distinction is the whole design. A role boundary is permanent and silent. A state boundary is temporary and explained, because “not yet, and here is why” is real feedback the product owes you. Four of the reasons the templates actually pass:

• Terms: “Wolf never accepts on behalf of a party. Acceptance is an authenticated action by each company’s Authorised Signatory.”
• Release: “The scope is not ready. Every blocker above must clear before an instruction can be prepared.”
• Approval: “Segregation of duties: you prepared this instruction, so you cannot approve it. A different authorised user must review it.”
• Cancellation: “No secured amount remains in the structure, so there is nothing a cancellation could return.”

Binding and financial actions carry a confirmation on top of the gate, and the dialog restates the specific entity, amount, destination or version, because a generic “are you sure” would prove nothing about what is being authorised. Every one of them closes on the same line: acting as this name and this role, and in production this step also requires strong authentication.

Every Escrow NEW step declares the persona that performs it, and the run compares that against the seat the reviewer currently holds. When they differ the bar swaps its right-hand button for Continue as the seat the step needs, naming it. One press takes that seat and keeps you on the same step, then routes to where the step happens.

Nothing is performed on your behalf and nothing is skipped. The button hands over the seat because who acts is part of what is being demonstrated: a flow that moves from Finance to a Signatory to Operations to an Approver is showing you the hand-offs, and quietly letting one person do all four would be showing you nothing. Stepping backwards through the strip takes the seat of the step you land on, for the same reason.

The controls themselves never soften. While you hold the wrong seat the step’s action is absent from the screen exactly as it would be in production, so the bar offering the seat is the only route forward.

AML Officer 3.0 never reports a wrong seat, and the adapter says why: the workspace has one operator, so there is no seat to take and a step is never blocked on being someone else.

Audit entries follow the same rule over three levels, and both checks are applied at the point documents and audit are read, so a filtered list is the only list a seat ever receives. There is no unfiltered view to leak.

A hold shows the same split on one record. Applying it writes a restricted reason alongside a client-visible summary and a client-required action, and the audit entry is written compliance-restricted for a compliance hold and Wolf-internal for an operational one. The engine states the intent on the record itself: clients see a neutral review status, and the reason stays internal. Removing a hold is deliberately not a release either, it triggers a re-evaluation of the state and does not move funds by itself.

One record produces three different navigations. A client seat gets a single group, Your transactions: dashboard, my work, escrows, documents, and requests and messages. Compliance gets one group of its own, adding compliance cases, custody clocks, release approvals and the audit trail to the dashboard, the work list and the escrows. Operations gets three groups: Operations, Workspaces (funding and reconciliation, FX desk, verification, release approvals, settlement monitoring) and Control. The sidebar prints the current seat’s role label above the list, so the answer to “why can I not see the FX desk?” is one glance away.

Work is scoped the same way. The task owner type enumerates eight owners and pointedly omits the Viewer: a read-only seat never owns a task. A notification carries an audience of owners, where an empty list means every seat on the transaction. Tasks and notifications are derived from the transaction rather than stored, so a hand-off appears for the next role the moment the previous action lands.

Preparing an instruction stamps the maker onto it, as an internal user id and as the acting name and role, and sets it to approval pending. The audit line written at that moment already states the rule: the maker cannot approve their own instruction.

Approval then opens with the guard, under the comment that the maker can never approve their own work. If the acting name matches the maker, the command returns the transaction unchanged. Rejection carries the identical guard, so a maker cannot dispose of their own instruction by returning it either. A rejection records a reason, cancels the legs and logs that it never alters the secured funds.

A successful approval writes the approver and the timestamp and logs the distinction the whole product turns on: approved by a user who did not prepare the instruction, and approved is not paid, because settlement has not started. Only submission sets the reversibility to the point of no return.

The acceptance suite tests the property rather than the intention. Its dual approval predicate requires an approval timestamp, an approver name, and an approver name that differs from the maker’s. The split-settlement scenario asserts that both legs passed maker-checker because a different user approved the instruction carrying them.

The scope of the rule is stated in the process narrative: every movement of secured client funds needs maker and checker for release, partial release, refund, split, cancellation after funding, residual return and manual re-instruction. No person may create the conditions and then unilaterally release the same transaction.

Preparation sets an extra approval requirement by a plain numeric comparison on the instruction amount: at or above 2,500,000 the tier is MLRO, otherwise none. When it applies, the prepared instruction logs that the value tier also requires MLRO sign-off.

The two approvals are ordered and cannot be collapsed into one. A four-eyes approval on a tiered instruction keeps it at approval pending and moves the state label to Awaiting MLRO, logging that the value tier still requires an additional sign-off before the instruction can be submitted. The MLRO command refuses to run at all unless the four-eyes approval is already on the record, so the second signature sits on top of the first rather than replacing it.

Only the MLRO holds extra_approval. He also holds approve_movement and may act as the ordinary checker, and the maker guard applies to him like anyone else. The approvals surface reflects all of this: it is titled Release approvals under the eyebrow Four-eyes control, it chips a warning that a second-tier approval is also required when the tier is set, and it shows the sign-off control only to a seat holding the capability. The narrative adds the two rules the prototype states about approval quality: approval requires strong authentication, rejection requires a reason and returns the instruction without touching the secured funds, and an approval lapses if any reviewed field or clearance changes before execution.

Entry is a single coarse gate. The route guard reads the shared session role and denies a client account with “This is the compliance workspace. Your account does not have access to it”, returning them to their portal after a few seconds. The two staff session roles, Admin and AML Officer, may both enter and the sidebar is the same for either. It is badged AML Officer 3.0, the product name in full, because the badge sits one column away from the top bar and a badge cut back to AML Officer would read as a fifth desk rather than as the name of the workspace.

That distinction is the one thing worth being pedantic about here. A login carries a job title from the shared session store, and neither of those titles is a seat: the operations login reads Operations Admin, and the compliance login reads AML Officer, which is the product again. So a small map turns the session role into one of the four seats, the header prints that seat under the name, and the guided run names the same four and nothing else.

Inside, separation is carried on the command rather than on the screen. Every AML command is appended to the log with an actor name and an actor role, defaulting to Anna Kowalska at the AML Special Unit, and a screen whose step belongs to a different seat passes that seat explicitly: Marcin Wilk as First Line of Defence on a monitoring note, Jan Brunner as Management on a decision, Tomasz Zieliński as Second reviewer on a confirmation. So the record knows who acted even though the interface never asked you to log in again. A guided step names the hat you are wearing for exactly that reason.

The Board owns the framework and approves the policy, and appears in no guided step: owning a framework is not work performed in a workspace. The other three are lines of defence and three of the four seats in the register above. The fourth, Second reviewer, is not a rank in the policy at all; it is whoever did not record the thing being confirmed.

The separation between the first line and the Special Unit is enforced as an ordering rule on monitoring statuses. A status is a set rather than a single value, because a transaction can be under investigation, awaiting information and already reviewed at once, and forcing that into one value loses the picture. What the set cannot do is skip a line of defence. The status check returns a verdict with a reason:

• Reviewed by the AML Special Unit needs a first-line note on the record: the first line has to analyse and comment on the hit before the Special Unit reviews it. The second line reviews the first line’s words, and a second line that reviews nothing is a rubber stamp.
• Plausible and not plausible exclude each other, are refused while information is still outstanding, and require a clarification that already carries a recorded result: the plausibility check has to be written down, not just flagged.
• Reporting to MROS needs a recommendation and then a Management decision. Without one, the refusal reads: Management decides on the recommendation, the Special Unit then executes, and no decision is on file.
• Approved by Management needs a recommendation first, because there is nothing for Management to approve until somebody has made one.

Removing a status is always permitted, because a wrong entry has to be correctable. The guidance line narrates the same chain in order: record the first-line analysis, have the Special Unit review it, open a special clarification, complete summary, documents and result, make a recommendation, then wait for Management.

Escalation crosses the line formally rather than by conversation. It sets the escalation target to the AML Special Unit, adds the investigation status, and opens a special clarification, because that is the form the policy requires for an additional investigation. The derive pass then applies the investigation criterion to the customer automatically, recorded as applied by the risk model and noted as applying irrespective of the outcome.

A person’s screening record carries the disposition and, separately, who confirmed it. Recording a disposition (mark false positive, or confirm true match) clears any earlier confirmation in the same write, so a new conclusion is never inherited as already confirmed.

The confirmation command carries the guard that the reviewer who recorded the disposition cannot confirm it. Worth knowing precisely what is wired today: the profile screen calls that command with the customer and the person only, and does not pass who recorded the disposition, so the engine guard does not fire from that screen. The separation is achieved by construction there instead. The control is labelled Second review as Tomasz Zieliński, runs as that named actor at the Second reviewer seat, and is disabled unless a disposition exists and no confirmation has been recorded yet.

The guided flow states the property it is proving: confirm the disposition as somebody who did not record it, and the reviewer who recorded it cannot be the one who confirms it. The seeded data shows the same pattern at rest, with confirmations attributed to somebody other than the recorder in every case.

A report case stores the recommendation, who made it and when; then the Management decision, who took it and when; then the filing and the MROS reference. Its state moves from drafting, to awaiting management, to filed or closed with no report. Three commands map one to one onto three seats.

• Recommend. The Special Unit opens the case at awaiting management, and the recommendation is stamped with the acting name and the Special Unit. The detail screen offers this only where the clarification result is something other than plausible with no suspicion, and the guided step says it plainly: the Special Unit recommends, it does not decide.
• Decide. The Reporting screen runs this as Jan Brunner at Management, through two buttons: decide to report, which moves the case to drafting, and decide not to report, which closes it. Both are disabled on empty text, so a decision without reasoning cannot be recorded.
• File. The command returns unchanged if there is no Management decision on the case, so the Special Unit cannot execute a notification that Management has not decided.

The completeness check adds the missing Management decision to the list of what a file still needs, which is why the screen can refuse to present a report as ready, and the goAML export emits an explicit marker for anything the platform cannot source rather than a plausible-looking invention.

The upstream half of the chain is enforced on the clarification form: recording a result is refused while the summary is empty, and both sending to Management and closing are refused without a result.

The customer profile honours this by offering Record the Management approval only where the category is not low. That matters to the authority model because the category is what pulls Management in, and the category is never stored: it is derived from the criteria on the file, high at a score of three or more, medium at one or two. It cannot be set by hand to avoid them.

The AML workspace reads the Escrow NEW transactions directly rather than keeping its own copy of a queue, so an officer looking at a case and an operations user looking at the transaction are reading the same record, and a scenario added on the escrow side appears in AML with no further wiring. Each escrow-driven case is paired with the policy duty it discharges: the seller screening case before payout, for instance, is labelled as ongoing screening of all involved persons, repeated immediately before every outgoing movement.

The people line up too, and each demo names them out of its own register. Escrow NEW spells a seat as a side and a title, and AML Officer 3.0 has the four seats above. Those are the two registers; there is no third spelling anywhere, and neither register is a variant of the other. So one person holds a seat in each demo, under two names, both of them exact:

• Anna Kowalska: Wolf · AML Officer in Escrow NEW. The AML Special Unit in AML Officer 3.0, which is the desk the engine assumes when a command names no actor.
• Jan Brunner: Wolf · MLRO / Director in Escrow NEW. Management in AML Officer 3.0, the seat the Reporting screen and the customer profile pass by name when he decides.
• Marcin Wilk: Wolf · Operations Maker in Escrow NEW. The First Line of Defence in AML Officer 3.0, on the monitoring note.

AML Officer is therefore three things and one thing it is not. It is the name of the product, the name of the compliance workspace, and the title of the Escrow NEW seat Anna Kowalska holds. It is not a desk inside AML Officer 3.0: the four seats there are First Line of Defence, AML Special Unit, Management and Second reviewer, and nothing in that workspace is attributed to anything else.

The join point in the lifecycle is compliance clearance. A compliance hold blocks release, refund, conversion and any change to the payout destination, and only the two Escrow NEW compliance seats, AML Officer and MLRO / Director, hold the capabilities to remove a hold or grant clearance. Operations can take a held transaction as far as the blockers and no further, and a prepared instruction stores the identifier of the cleared case it relies on, so the approver reads the clearance the instruction was built on rather than whatever the case file happens to say later.