Brief

From rule to workflow

A practical decision record for regulatory ambiguity

Claire FausettPublished Last reviewed 9 min read

Bottom line

Compliance ambiguity gets handled as a research problem: find the governing rule and read it closely. Research is the smaller half. The team still has to know which decision is on the table, whose authority covers it, which facts carry the answer, how much uncertainty survives, and how the same question gets the same answer the next time it arrives. A useful compliance conclusion therefore ends in a workflow rather than in a citation.

1. Define the actual decision

Most questions arrive as a subject rather than as a decision. “Do we have a problem with this customer’s ownership structure?” names a subject. Turning it into a decision takes five lines:

  • What is being requested, and by whom?
  • For which customer, product, or process?
  • By when, and what follows if the answer arrives after that?
  • Which part of the question is genuinely uncertain?
  • Who holds the authority to answer it?

The fourth line does the most work. Most requests carry one contested element wrapped in a great deal of settled context, and an analyst who answers the whole question spends three days restating what was already clear. Isolate the contested element and the analysis shrinks to something a business can wait for.

2. Separate the three layers

  1. Authoritative requirement
  2. Company policy and risk appetite
  3. Operational implementation

Weak compliance writing blends these three, and the blend is what makes a firm rigid.

  • The requirement is what a binding rule obliges. The beneficial-ownership rule, for instance, obliges a covered institution to identify and verify the beneficial owners of legal entity customers, at a 25 percent equity threshold plus one control person.
  • The policy is where the firm chose to stand. A firm may collect ownership below the regulatory threshold, or hold every product to the standard that reaches only some of them. That is risk appetite, and it belongs to the firm.
  • The convention is what the operating team actually does: the checklist naming three acceptable documents, the second signature somebody added after an awkward audit, the form field marked mandatory in 2019 by a person who has since left.

Each layer is legitimate. The failure is silent promotion, where a convention gets described as a requirement and then defended as one. Once that happens, exceptions escalate as though they were breaches, an operations lead loses the standing to propose a better process, and the firm has quietly handed its risk appetite to whoever wrote the checklist.

So ask of any rule a team follows: which layer is this, and who may change it? A requirement changes when the regulator changes it. A policy changes when the firm decides. A convention changes on Tuesday.

3. Identify material facts and assumptions

State them in this order, and state them plainly:

  • Facts known, each with its source
  • Facts missing
  • Assumptions standing in for the missing facts
  • The fact that would change the conclusion
  • Which source governs where two of them disagree

The fourth line is the most valuable in the record. It tells a reader what to watch and an escalation what to ask for, and it converts a hunch into a testable position. It also ages well: when the assumption breaks, the record says so.

4. Generate real options

Yes and no are the two ends of a range with a great deal inside it:

  • No
  • Yes
  • Yes, with additional evidence
  • Yes, with compensating controls
  • Yes, with enhanced monitoring
  • Temporary approval carrying a review date
  • Escalation, because the residual uncertainty exceeds the decision-maker’s authority

The middle of that list is where compliance earns its standing with the business. “Yes, with enhanced monitoring for two quarters and a review date of 1 March” is a decision. Bare yes is a hope. Bare no is often a convention wearing a requirement’s clothes.

Escalation earns its own line because it belongs to the shape of the authority rather than to the confidence of the analyst: a well-run function escalates on the boundary rather than on the feeling.

5. Use a repeatable decision record

Field What it captures
Decision requested The specific question, as an answerable decision
Business objective Why the answer matters to the business
Governing requirement The authoritative source, cited
Relevant policy position Where the company has chosen to stand
Material facts What is known, and from where
Known uncertainty What remains unknown, stated plainly
Options considered The realistic paths, beyond yes and no
Recommended path The defensible choice
Required controls or conditions What must be true for the path to stay safe
Decision owner Who is accountable
Review trigger or expiration date When the answer must be revisited

Same fields, every time. The value shows up later, when somebody asks whether the answer was reasonable on the day it was given rather than whether it turned out well. A record holding its uncertainty in the open survives that question; a memo that smoothed the uncertainty away fails it.

6. Translate the decision into a workflow

  • What data must be collected, and into which field?
  • What evidence is acceptable, and what makes it stale?
  • Which system event triggers the check?
  • What proceeds automatically?
  • What routes to a person, and to which queue?
  • Who owns an exception?
  • How is the decision recorded on the customer file?
  • When must it be revisited, and who receives that date?

A decision that stops at the recommendation lives in one inbox. A decision naming the field, the trigger, the queue, the exception owner, and the record survives that person’s vacation, promotion, and departure.

A worked hypothetical

The following scenario is hypothetical and is included only to illustrate the framework. The company and the country below are invented.

The question as it arrived. A payments company plans to open payouts to sellers incorporated in a country it has so far served only as a buyer market. Operations asks which document proves a seller is a real registered entity, and whether the national registry extract available there qualifies. Launch is eleven weeks out.

1. The decision. Approve, decline, or condition the use of that registry extract as documentary verification of entity existence, in time for a launch eleven weeks out, under the authority of the head of onboarding policy. The contested element is narrow: whether the extract issues from an authoritative source, and whether it evidences ownership as well as existence.

2. The layers. The requirement obliges verification of the entity’s identity through documentary or non-documentary means, and it names no list of acceptable documents. Policy requires documentary verification to come from an independent, authoritative source. Convention is a checklist naming three document types; the extract sits outside it, and the analyst read that absence as a prohibition. It is a gap in a list.

3. Facts. The registry is run by a government ministry, is publicly searchable, and returns name, registration number, legal form, incorporation date, and address. Missing: whether an extract shows current ownership or the founding record. Assumption: it updates on filing rather than continuously. The fact that would change the conclusion: whether each record carries a visible last-filing date.

4. Options. Decline. Approve outright. Approve where the extract carries a filing date inside twelve months. Approve for existence and legal form, with ownership evidenced separately. Approve under a stated risk tier with enhanced monitoring. Escalate.

5. The record. Recommended path: accept the extract for existence and legal form, with ownership evidenced from a second source. Conditions: a filing date inside twelve months, ownership captured before the first payout, quarterly sampling for two quarters. Owner: head of onboarding policy. Expiry: twelve months, or the day the registry changes its publication format.

6. The workflow. Add the extract to the accepted-documents list with its date condition attached, and a required field for the filing date so the condition is enforced by the form rather than by memory. Route sellers whose ownership is missing to a named queue with an owner. Stamp the decision identifier on the customer file, so a reviewer two years later can see which decision produced the outcome.

The research answer ran to a paragraph. The workflow is what launched.

7. Measure whether the answer worked

  • Decision turnaround, from request to recorded answer
  • Repeat questions on a settled subject
  • Exception recurrence and rework
  • Override rate against the recommended path
  • Quality-assurance defects traced to the guidance rather than to the operator
  • Control failures found downstream
  • Friction reported by customers, and by the operators applying the rule

Repeat questions are the most honest measure here. A question returning three times has an answer that failed to travel, and the fix belongs to the guidance rather than to the person asking.

What this changes operationally

A compliance analyst stops treating the memo as the deliverable. The deliverable is the record plus the workflow change, with the memo attached as the reasoning behind them.

An operations lead gains one question to ask of every rule the team follows: which layer is this? Conventions become improvable, and requirements become visible as the small set they usually are.

A product manager gets a shape to bring questions in — the request, the customer set, the deadline, and the cost of delay — which is most of what makes an answer fast.

A manager reads the question queue as a reporting line. Three repetitions of one question is a defect in the guidance, with a name and an owner.

Limitations

This framework organizes a question; the answer still comes from legal analysis, subject-matter expertise, and escalation. It rests on an assumption worth checking: that somebody holds written, delegated authority over the decision. Where that authority is vague, the record documents an ambiguity rather than resolving it, which is useful and falls well short of sufficient.

It assumes, too, that the governing requirement is legible. Where the requirement itself is contested, the honest output is an escalation carrying the uncertainty on its face, rather than a recommendation dressed as a conclusion.

Primary sources

  • FFIEC. Bank Secrecy Act/Anti-Money Laundering Examination Manual. Risk-based internal controls, and the expectation that policies, procedures, and processes are documented and applied consistently.
  • FinCEN. Customer Due Diligence Requirements for Financial Institutions, 31 CFR 1010.230 (2016). The beneficial-ownership obligation used as the binding layer in the worked example.
  • Board of Governors of the Federal Reserve System and OCC. Supervisory Guidance on Model Risk Management, SR 11-7 / OCC Bulletin 2011-12 (2011). Documentation and effective challenge as supervisory expectations.
  • COSO. Internal Control — Integrated Framework (2013). Control activities as the point where a policy becomes a repeatable process.
  • Institute of Internal Auditors. The IIA’s Three Lines Model (2020). Separating the party that owns a risk from the party that assesses it.