SOP Writing Standards

Core components

Know which document you're writing

Most SOP problems start with one document doing the job of three. Keep these separate and link between them.

Rules of thumb:

• A policy says what and why. An SOP says how and when. If an SOP sentence starts "We believe…" or "Our approach is…", it belongs in policy.
• A job aid only presents what the SOP already says. If it contains a rule the SOP doesn't, you now have two SOPs.
• A calibration ruling is temporary. Every ruling that changes how decisions are made must land in the SOP within a set window (see Fraud QA Program), or the log becomes a shadow SOP.

Lead with the decision

Analysts open an SOP mid-case with a specific question. Structure the document around the decision they're making, not around the history of the alert or the mechanism.

A decision-oriented review SOP has, in this order:

1. The decision. One sentence: "Decide whether to release, extend the hold on, or decline and restrict a withdrawal flagged after a payout destination change."
2. Allowed outcomes. An enumerated list of dispositions and actions, each with its reason codes. If an outcome isn't on the list, the analyst can't choose it.
3. Stop conditions first. Mandatory escalations and hard stops (suspected scam victim, elder exploitation, insider indicators, law enforcement request, legal threat) are checked before any release logic. Analysts who find a stop condition halfway through a release workflow often finish the release anyway.
4. Minimum evidence. What must be checked before each outcome (see below).
5. Decision logic. A tree, a matrix, or both.
6. Edge cases and counter-examples.
7. Escalation paths.
8. Documentation, reason codes and customer communication.
9. Reference material. Background on the mechanism goes last, as a link to the mechanism note or playbook. A short "why" line on each step stays inline, because it helps analysts handle cases the SOP didn't predict.

Decision trees and matrices

Use a tree when order matters: gates that must be passed in sequence (stop conditions, then verification, then risk). Use a matrix when two or three factors combine into an outcome. Many SOPs need both: a tree to reach the matrix, and the matrix to make the call.

Rules for decision logic:

• Every path ends in an allowed outcome. There are no dead ends, and no "use judgment" cells that leave out the factors judgment should weigh.
• Use two or three dimensions at most. A matrix with four or more dimensions is a scoring model, so build it in the Rules Engine or a model and give the analyst the score.
• Define every row and column with evidence. "High-risk destination" means nothing unless the SOP says what makes it high-risk, ideally a tier shown in the review UI.
• Include the missing-data path. If a required evidence source is unavailable (tool outage, vendor timeout), the SOP must say what to do. Silently treating missing as clean is how outages turn into losses (see Fraud Incident Response).
• Put the default on the safe side for money that hasn't left (hold, escalate), and on the customer-friendly side for low-value, reversible outcomes. Write the default down per queue (see Alert Review Operations).

The tree is generic on purpose. The specific signals, tiers and thresholds that feed it belong in the members playbooks, labeled illustrative.

Evidence requirements

The single most useful thing an SOP can do for QA is define what "checked" means.

• Name the source. Write "Review the linked-accounts panel in the case view" instead of "check for linked accounts."
• Name the comparison. Write "Compare the destination account holder name with the account holder name" instead of "review the destination."
• Name the record: what must appear in the case for QA to see the check happened (a field, a screenshot, a narrative line).
• Define evidence for releases too. Many SOPs list evidence for declines and say nothing about approvals, so releases get rubber-stamped. Define a minimum evidence set for every outcome, including release.
• Set the bar for adverse action. What evidence is sufficient to decline, close or claw back? Adverse action without a documented basis is an auto-fail in most QA programs, and in regulated flows it's a complaint and examination risk.
• Use evidence as of decision time. State that decisions are made, and graded, on what was visible at the time. Your Case Management Systems should snapshot it.

Examples and counter-examples

Every decision point gets at least one example ("this is a duplicate receipt") and one counter-example, a near miss ("this looks like a duplicate but isn't, because the store reprinted the receipt after a return"). Examples teach recognition. Counter-examples prevent over-application, which shows up as false blocks.

• Use synthetic or fully sanitized cases. No real customer data in SOPs, which are widely distributed and long-lived.
• Mark each example with the SOP version and date. Retailer receipt layouts, bank-link flows and review UIs change, and stale screenshots teach the wrong thing without anyone noticing.
• Source counter-examples from QA disputes that were overturned and from analyst questions. Those are the cases where the SOP already failed once.

Edge cases

Keep a dedicated edge-case section, each entry with a ruling and a date. The ones transaction fraud SOPs most often miss:

Escalation paths

For each escalation, specify:

• Trigger: the observable condition, in evidence terms
• Destination: queue, team or role (not a person's name)
• Money state while waiting: hold, partial hold, restrict exits only, or none
• Handoff contents: what the receiving team needs in the case
• SLA and SLA-expiry behavior
• Authority limits: a delegation-of-authority table setting which analyst tier can release or decline up to which amount, and which actions (account closure, clawback, law enforcement disclosure) need a second approver

Mandatory escalations typically include suspected money laundering or SAR-relevant activity (BSA-AML and SAR Filing), suspected elder exploitation, insider indicators (Insider Fraud), law enforcement requests, legal or media threats, regulatory complaints, and Reg E error claims routed to the claims process (Regulation E and Unauthorized Transfers).

Mapping SOPs to the QA rubric

QA can only be fair if it scores what the SOP requires, and nothing else. Build the mapping in from the start.

1. Give every step a stable ID (WDR-3.2: queue prefix, section, step). IDs never get reused; if a step is deleted, its ID retires.
2. Use requirement language deliberately:
   • must → a scored rubric item; a critical item where the step protects money, customers or regulatory obligations
   • should → a non-critical item or a coaching note
   • may → not scored; analyst discretion
3. Map every "must" to a rubric item, or mark it explicitly "not scored," with a reason (usually "not observable in the case record"). If QA can't see whether a step happened, either add a record requirement or stop calling it a must.
4. Make every rubric item cite the SOP step it enforces. A rubric item with no SOP citation is a rule nobody wrote down.
5. Score against the version effective at decision time. A decision made the day before a change is graded on the old SOP, so QA tooling should store the SOP version with each case.
6. When you change one, review the other. Every SOP change triggers a rubric check, and every rubric change cites the SOP change that prompted it.

The traceability table under Artifacts and templates makes this concrete. Rubric design itself (critical items, auto-fails, weights) is covered in Fraud QA Program.

Writing style for analysts

Write for a tired analyst on case 140 of a shift, possibly working in a second language at an outsourced site.

• Use imperative mood, active voice and present tense: "Verify the customer by calling the phone number on file before the change." EPA's SOP guidance and the federal plain language guidelines both recommend this style for procedural documents.
• Put one action in each step. If a step has "and," consider splitting it.
• Put the condition first, then the action: "If the destination is less than N days old, extend the hold." Analysts scan for the condition that matches their case.
• Use "must" for requirements. Avoid "shall," "should consider," "as appropriate," and "where necessary," because each of those becomes a calibration argument.
• Define terms once, link to the Glossary, and use them consistently. "Payout destination," "withdrawal account" and "linked bank" shouldn't all mean the same thing in one SOP.
• Use tables instead of paragraphs for anything with more than two conditions.
• Bold the decision and leave the background plain.
• Leave out idioms, sarcasm and internal slang. They don't translate, and outsourced teams interpret them literally.
• Point to thresholds rather than copying them. "Use the destination risk tier shown in the case view" survives a rule change. A number pasted into the SOP doesn't, and it leaks.

The "before" version can't be scored. The "after" version produces three rubric items with observable evidence.

Versioning, change control and effective dates

Treat SOPs like code: versioned, reviewed, released on a date, and reversible.

Practices that matter:

• Publish date and effective date are different fields. Publish early, take effect after training is done. For BPO teams, allow for their training cycle.
• QA transition window. For the first one to two weeks after a major change, score the new step as coaching-only, then switch to full scoring. Write the window into the release note so nobody argues about it later.
• One source of truth. Read-only for analysts, editable only by owners. Archive old versions so they can't be used by accident but can be retrieved for audits, disputes and look-backs. EPA's SOP guidance makes the same point about withdrawn procedures.
• Change log at the top of the SOP: version, effective date, what changed, why, and the finding or rule change that triggered it.
• Link SOP changes to rule changes. A new rule that sends alerts to a queue needs SOP coverage before it goes live. Add "SOP impact" to the rule change checklist in Rule Governance and Change Management, and estimate the handle-time impact for Workforce Management and Capacity Planning.

Governance

RACI

Compliance sign-off is mandatory for steps touching regulated obligations: Reg E error resolution and provisional credit, SAR referral, funds availability notices (Regulation CC and Funds Availability), customer communications that could raise UDAAP concerns, and adverse-action messaging. In regulated firms, second-line oversight may sample SOP changes (see Three Lines of Defense).

Review cadence

• Event-driven reviews (these catch most problems): a rule or model change feeding the queue, a product or UI change, a regulatory change, a systemic QA finding, an incident or post-mortem, or a spike in analyst questions.
• Periodic reviews: quarterly for high-volume or money-out queues, at least annually for everything else. EPA's guidance suggests every one to two years for stable laboratory procedures. Fraud procedures go stale much faster because the adversary moves.
• Inventory: keep a master list of SOPs with ID, title, owner, version, effective date, next review date, linked queues and rules, and linked rubric. An SOP whose owner has left stops getting updated.

Training and attestation

• Write release notes for every minor or major change: what changed, why, what to do differently, and one worked example.
• Train before the effective date for major changes, using short scenario walk-throughs rather than slide reads.
• Track attestation ("I have read and understood v4.0") in your LMS or case tool. Make it per version, and make queue access depend on it for major changes.
• Add knowledge checks for major changes: three to five scenario questions that need the new step to answer correctly. Recall questions ("what is step 3.2?") only test memory.
• Attestation doesn't prove comprehension. The real test is QA error rate on the changed step during the first 30 days. If it spikes across many analysts, the problem is the SOP or the training.
• For outsourced teams, the vendor runs attestation, but you verify it through records and a sample of your own knowledge checks. Version drift between in-house and outsourced copies is a common, silent failure.
• New analysts learn SOPs inside a structured curriculum (Fraud Analyst Onboarding Curriculum). Frontline support uses simplified job aids derived from the same SOPs (Support Team Fraud Training, Customer Support Verification Protocols).

Artifacts and templates

SOP outline template (copy and adapt)

0. Header. SOP ID · Title · Queue(s) · Version · Publish date · Effective date · Owner (role) · Approvers · Next review date · Linked rubric version · Linked rules and model versions · Access classification

1. Change log. Version · Effective date · Change summary · Reason (finding ID, rule change, regulation) · Training required (Y/N)

2. Decision and scope

• 2.1 The decision, in one sentence
• 2.2 In scope: alert types, rules, products, rails
• 2.3 Out of scope, and where those cases go

3. Allowed outcomes. Table: outcome · action in tool · reason codes · customer message template · reversibility

4. Stop conditions and mandatory escalations (checked first)

5. Minimum evidence by outcome. Table: evidence item · source (screen or panel) · what to compare · what to record · required for which outcomes

6. Decision logic

• 6.1 Decision tree
• 6.2 Decision matrix, with every row and column defined
• 6.3 Missing-data and outage path
• 6.4 SLA-expiry default

7. Edge cases. Each with ruling, date and the calibration ruling ID it came from

8. Examples and counter-examples. Each tied to a step ID

9. Escalation paths. Trigger · destination · money state · handoff contents · SLA

10. Delegation of authority. Analyst tier × action × dollar limit

11. Documentation. Narrative standard (see Case Documentation Standards), required fields, reason-code definitions (see Fraud Labeling and Feedback Loops)

12. Customer communication. Approved templates, and what never to say (for example, revealing which signal triggered the review)

13. Regulatory clocks. Any deadlines this queue can trigger or breach

14. References. Policy, playbook, mechanism notes, job aids

15. Rubric traceability table

Sample decision matrix (illustrative format)

Cashback receipt review. Rows and columns must be defined in the SOP with evidence. The specific checks and the linkage criteria belong in the members playbook, Playbook - Receipt and Offer Fraud Members.

It's usable because every cell is an allowed outcome, rows and columns are observable, and escalation is built into the cells instead of left to judgment. The same pattern works for a brokerage withdrawal (verification outcome × destination risk tier) or a marketplace claim (evidence of delivery × claimant history).

SOP-to-QA rubric traceability (example)

Rubric item numbers refer to the sample rubric in Fraud QA Program.

Run two checks on this table every release: look for any must without a rubric item (an unenforced requirement), and any rubric item without an SOP step (an unwritten rule).

SOP review checklist

• The decision is stated in one sentence at the top
• Every outcome has a reason code and a customer message template
• Stop conditions are checked before release logic
• Minimum evidence is defined for every outcome, including approve or release
• Every matrix cell and every tree leaf ends in an allowed outcome
• The missing-data path and SLA-expiry default are written down
• Each decision point has at least one example and one counter-example
• Every "must" maps to a rubric item or is marked "not scored" with a reason
• No pasted thresholds that duplicate rule configuration
• No real customer data in examples or screenshots
• Regulated steps have compliance sign-off
• Tested by someone other than the author on a set of gold cases
• Release note, training and attestation planned for the effective date

Metrics

Report these to the SOP owner monthly with the QA findings register. Each month, ask which SOP step generated the most errors, disputes and questions, and what you're changing about it.

How to build it

Start with the queues where money leaves (withdrawals, payouts, redemptions) and where customers are harmed by false blocks (claims, account closures). Those are where ambiguity costs the most.

Pitfalls

• Background essays before the decision. Analysts skip them, and the one important caveat in paragraph four goes unread.
• "Use your judgment" with no factors. That makes QA a matter of taste and calibration a recurring argument.
• Unscoreable requirements. "Thoroughly review" and "as appropriate" can't be audited.
• Evidence defined only for declines. Releases get rubber-stamped, and false releases are where the money goes.
• Shadow SOPs. Pinned chat messages, team-lead spreadsheets and calibration rulings that never make it into the document.
• SOPs written per rule instead of per decision. Twenty rules feeding one queue should produce one SOP with twenty triggers.
• Version drift between in-house and outsourced teams, or between the SOP and its job aids.
• No outage path. The day the linkage tool is down, analysts improvise.
• Pasted thresholds. They go stale when the rule changes, and they leak. SOPs are widely distributed documents, so assume an insider or vendor employee can read them (Insider Access Controls).
• Verbatim legal text. Quoting the regulation isn't a procedure. Translate obligations into steps, and have compliance confirm the translation.
• Training without measurement. Attestation rates at 100% and error rates up 40% on the changed step tell you the release failed.

Related

• Operations: Alert Review Operations · Fraud QA Program · Investigation Standards · Case Documentation Standards · Manual Review Queues · Case Management Systems · Workforce Management and Capacity Planning · Fraud Tabletop Exercises
• Governance: Rule Governance and Change Management · Three Lines of Defense · Fraud Operating Model · Friction and Customer Experience Tradeoffs
• Labels and data: Fraud Labeling and Feedback Loops · Entity Resolution
• People: Fraud Analyst Onboarding Curriculum · Support Team Fraud Training · Customer Support Verification Protocols
• Regulatory steps SOPs often encode: Regulation E and Unauthorized Transfers · BSA-AML and SAR Filing · Regulation CC and Funds Availability
• Playbooks that hold queue-specific criteria: Playbook - Payout and Withdrawal Risk Members · Playbook - Receipt and Offer Fraud Members · Playbook - Scam Intervention Members
• Hub: Fraud Program Overview

Sources and further reading

• U.S. EPA, Guidance for Preparing Standard Operating Procedures (EPA QA/G-6, 2007): SOP purpose, step-by-step style in active voice and present tense, testing by someone other than the author, document control, review every one to two years, archiving withdrawn versions
• Federal Plain Language Guidelines (2011 revision, as republished by FAI): writing for the reader, active voice, "must" for requirements, short sections, lists and tables
• McHugh, Interrater reliability: the kappa statistic (2012, PubMed Central): why item-level agreement statistics show where a written standard is ambiguous
• COSO/ACFE Fraud Risk Management Guide, 2nd ed., Executive Summary (2023): documented control activities and ongoing monitoring as fraud risk management principles
• CFPB, Regulation E §1005.11 Procedures for resolving errors: an example of regulatory clocks that SOP steps must encode and QA must check
• eCFR, 31 CFR 1020.320 Reports by banks of suspicious transactions: SAR timing that makes escalation steps mandatory and critical