Segregation of Duties (SoD)
Segregation of duties (SoD) is the internal control principle that no single operator can book, approve, and settle a transaction — enforced through conflict matrices, maker-checker workflows, and access certification reviews to satisfy SOX Section 404.
Definition
Segregation of duties (SoD) is a foundational internal control principle that prevents a single individual from executing two or more steps in a business process that, when combined, create a material control risk of fraud or error. In financial services, SoD is embedded in the Control Activities component of the COSO Internal Control — Integrated Framework, serves as a core control activity used to satisfy the internal control over financial reporting (ICFR) requirements of Sarbanes-Oxley Act Section 404, and is operationally tested through supervisory control reviews required under FINRA Rule 3120 and firm supervision programs under FINRA Rule 3110. Financial software that enforces SoD does so at the system level — assigning roles that carry mutually exclusive permissions, scanning for toxic access combinations before they reach production, and generating an immutable audit trail that documents who performed each step and when.
The core principle — conflicting roles and the risk of fraud
The SoD requirement exists because access management alone is insufficient. A system that grants a single operator the ability to book a trade, authorize its settlement, release the payment instruction, and reconcile the resulting position against the firm's books contains a complete fraud circuit: one person can initiate, approve, execute, and conceal a fictitious transaction without any independent check. SoD controls break this circuit by enforcing role separation at each control gate through the conflict matrix — a rule library that defines toxic access combinations: permission pairs that, when held by a single operator, constitute a material control risk. The operator who books the trade — the maker — cannot also be the checker who approves it. The operator who releases the settlement instruction cannot also be the person who reconciles the settled position. These controls fall under the Control Activities component of the COSO Internal Control Framework — they are not policy preferences but structural enforcement requirements for any firm attesting to the effectiveness of its ICFR under SOX Section 404. When management identifies SoD gaps during a Section 404 assessment, they represent some of the most commonly cited material weaknesses in broker-dealer internal control environments.
SoD in post-trade operations — the four functions that must be separated
Post-trade operations present a specific SoD requirement that differs from general ERP environments. Four functions must be held by distinct roles: trade capture (entering the trade into the order management or middle-office system), trade authorization (approving the trade details and releasing the settlement instruction), settlement execution (delivering the instruction to the central securities depository or custodian), and reconciliation (verifying that the settled position matches the firm's books and the counterparty's record). When any two of these functions reside in the same operator's role profile, the firm has a material SoD gap. SoD controls enforce separation through a conflict matrix — a rule library that specifies which permission combinations are toxic access combinations — and block the conflicting access assignment before it reaches the role provisioning stage. In enterprise resource planning (ERP) environments, where invoice entry and payment execution functions may exist within the same module, this conflict detection layer is the primary defense against access accumulation over time. Importantly, SoD financial software functions as an enforcement layer on top of existing systems — it does not require replacing the firm's ERP or OMS, but integrates the conflict matrix into the access provisioning workflow so that the separation requirement is enforced at the point of role assignment, not discovered after the fact in an audit.
SoD control zones in post-trade operations — role separation requirements
| Function | Role | Conflicting With | Regulatory Anchor | Compensating Control if Unseparated |
|---|---|---|---|---|
| Trade booking | Maker | Trade authorization | FINRA Rule 3120 / COSO | Supervisor daily review of same-day entries |
| Trade authorization | Checker / supervisor | Trade booking | SOX Section 404 / COSO | Automated conflict alert + override log |
| Settlement instruction release | Settlement ops | Trade authorization | CSDR / SEC 15c3-3 control environment | Dual-signature requirement on instruction file |
| Reconciliation | Middle-office / finance | Trade booking or settlement | SOX Section 404 / FINRA 3120 | Independent reconciliation team or outsourced function |
| General ledger posting | Finance / accounting | Trade booking | SOX Section 404 / SEC 17a-3(a)(2) | Read-only access to booking system; write access to GL only |
Compensating controls — when full separation is not achievable
Smaller operations teams frequently face a practical constraint: full role separation requires more staff than the firm employs. The COSO framework and SOX guidance both recognize this through the concept of the compensating control — an alternative control activity that satisfies the risk management objective when organizational constraints prevent hard separation. In post-trade contexts, common compensating controls include enhanced supervisory review (a senior operator reviews and attests to all transactions where the maker and checker are from the same small team), automated exception reporting (the system flags any transaction where the entry and approval user IDs match or share a reporting line), mandatory dual-signature on settlement instruction files, and read-only access to booking systems for reconciliation staff. Compensating controls must be documented, tested, and included in management's Section 404 assessment — they are not informal workarounds but formally attested alternatives that SoD software can monitor and report on.
Sarbanes-Oxley, FINRA Rules 3110 and 3120, and the audit trail requirement
SOX Section 404 requires management to assess and attest to the effectiveness of internal controls over financial reporting annually. SoD is a core control activity used to satisfy this requirement — SoD gaps in trade booking, general ledger posting, and settlement authorization are among the most frequently cited deficiencies in broker-dealer Section 404 assessments. FINRA Rule 3120 requires broker-dealers to establish a supervisory control system and produce an annual report to senior management documenting the results of that system's testing — SoD controls must be designed, tested, and the test results captured in that annual report. SoD software must therefore produce the Rule 3120 annual report output automatically: a conflict report showing which role combinations were tested, which exceptions were identified, what override steps were taken, and management's response to each finding. FINRA Rule 3110 (Supervision) independently requires that supervisory procedures be adequate to detect and prevent violations — SoD control design at the workflow level is a direct Rule 3110 requirement. SoD controls also support compliance with SEC Rule 17a-4 by limiting which operators can modify or delete electronic records — Rule 17a-4's tamper-evident storage and access control requirements are reinforced by SoD enforcement over the recordkeeping system itself.
Privileged access — the SoD gap that conflict matrices miss
Privileged system administrators present a unique SoD challenge that application-layer conflict matrices cannot fully address. A database administrator or operations administrator with direct production access can modify records, alter approval sequences, or delete audit log entries in ways that bypass the SoD controls enforced at the application level. This means that effective SoD in financial systems requires a second control layer: privileged access management (PAM) controls that monitor, record, and restrict what privileged users can do in production environments, independent of the application's own conflict matrix. FINRA examinations increasingly include review of privileged access controls as part of supervisory control system testing — the question is not just whether application users are appropriately separated, but whether system administrators can override those separations without detection.
Digital asset operations — quorum-based authorization as the SoD analog
Digital asset operations introduce a new dimension to the segregation of duties requirement. Private key management for digital asset wallets presents a material control risk with no direct analog in traditional settlement: a single custodian who holds a complete private key can unilaterally move client assets. The operational response — multi-signature authorization, where a transaction requires cryptographic approval from key shards held by distinct individuals in distinct roles — is the digital asset analog of the maker-checker workflow. In 2026 institutional operations, this extends beyond simple multi-sig to quorum-based authorization: the approval requirement is not merely "two of three signatures" but "one authorized person from Compliance plus one authorized person from Operations," enforcing both the count and the role separation. Multi-party computation (MPC) key management systems implement this quorum policy at the cryptographic level, distributing key shards so that no single individual or department can construct the full signing key unilaterally. The critical advantage of digital rail SoD is immutability: while a rogue administrator with database access could theoretically alter an application-layer approval log, the maker and checker authorizations recorded in the transaction metadata on a blockchain or private side-chain are cryptographically enforced — they cannot be modified after the fact without invalidating the transaction record itself. SEC guidance on digital asset custody has emphasized controls equivalent to those required for traditional securities, including separation of authorization authority over wallet transactions. SoD financial software applied to digital asset operations must therefore extend its conflict matrix to cover wallet authorization workflows: the operator who initiates a withdrawal cannot also hold a key shard sufficient to authorize it unilaterally.
SoD enforcement — single-operator path vs separated roles
Devancore Glossary · devancore.com
SoD enforcement — single-operator path vs separated roles
Devancore Glossary · devancore.com
How it works
1. Role design and conflict matrix configuration
Before any trade is processed, the SoD software requires the firm to configure a conflict matrix — a rule library that specifies which permission pairs are prohibited. In post-trade operations, the foundational conflicts are: trade booking plus trade authorization (maker and checker cannot be the same person), settlement instruction release plus reconciliation (the operator who releases cannot verify their own release), and general ledger posting plus trade booking (the same operator cannot book a trade and record the accounting entry). The conflict matrix is configured by the compliance or operations control team and reviewed as part of the annual WSP testing cycle required under FINRA Rule 3120. Once configured, the matrix governs every subsequent role provisioning decision.
2. Role provisioning with real-time conflict detection
When a new user is onboarded or an existing user's role is modified, the SoD software scans the proposed role assignment against the conflict matrix before the access change is activated. If the proposed assignment would grant the user two permissions that the conflict matrix designates as incompatible — for example, booking access in addition to authorization access — the system blocks the provisioning and generates an alert for the access management team and the operator's supervisor. This real-time conflict detection prevents the most common source of SoD gaps: access accumulation during staff transitions, system migrations, or headcount gaps where temporary overrides are granted and never revoked.
3. Maker-checker enforcement at the transaction level
At the transaction level, the maker-checker workflow is the operational instantiation of the SoD requirement. The maker — the operator who books the trade or enters the data — submits the record for review. The checker — a distinct operator with authorization permissions but not booking permissions — reviews the record, confirms the details, and approves the transaction. The SoD software enforces that the maker and checker user IDs are distinct and do not share a prohibited conflict combination. The approval is timestamped and logged immutably. In post-trade environments, this chain extends through settlement instruction release: the settlement ops team receives an approved trade record and releases the DvP instruction to the CSD or custodian — with their own role scope limited to instruction release and not extending to the upstream booking or approval steps.
4. Reconciliation by an independent role
Reconciliation — the verification that the firm's books match the settled position at the custodian or CSD — must be performed by an operator whose role is separated from both the booking and settlement instruction functions. SoD financial software enforces this by granting reconciliation staff read-only access to the settled trade record and the custodian position feed, without write access to the booking system. Discrepancies identified in reconciliation are escalated through an independent exception management workflow, not resolved by the reconciliation operator directly — preventing the same person from both identifying and closing a break in a way that conceals an error or unauthorized transaction.
5. Exception and override management with full audit trail
In any operation, exceptions arise: a time-critical settlement may require a supervisor to override the standard maker-checker workflow. SoD software manages overrides through a dedicated exception workflow — the supervisor who authorizes the override must authenticate separately, record the business justification, and approve within their own role scope. The override is logged immutably alongside the original transaction record. At the end of each period, the exception log feeds directly into the FINRA Rule 3120 supervisory testing report, allowing management to attest that overrides were reviewed, documented, and not used systematically to circumvent SoD requirements.
6. Periodic access certification and SOX attestation
SoD controls degrade over time as role assignments change. To maintain effectiveness, SoD software generates periodic access certification reviews — typically quarterly — prompting managers to re-attest to each team member's role assignments and confirm that no prohibited conflict has accumulated. Certification results feed into the SOX Section 404 evidence package, providing management with the audit-ready documentation required to attest to the effectiveness of internal controls over financial reporting. Failed certifications — where a conflict is identified and not remediated — are escalated to the chief compliance officer and documented as a control deficiency in the Section 404 assessment.
Post-trade SoD workflow — maker-checker enforcement chain
Devancore Glossary · devancore.com
Post-trade SoD workflow — maker-checker enforcement chain
Devancore Glossary · devancore.com
In Devancore™
Devancore SoD engine — post-trade control enforcement
Devancore Glossary · devancore.com
Devancore's post-trade operations platform enforces segregation of duties at the workflow level — not as an overlay policy tool, but as a structural constraint built into the trade lifecycle from booking through reconciliation. Every workflow step carries a role scope, and the system enforces that the operator performing each step holds the correct role and does not hold a conflicting permission from an upstream or downstream step.
Maker-checker engine — configurable conflict matrix for post-trade workflows
The Arc Network's maker-checker engine allows compliance and operations teams to configure the conflict matrix for each workflow type: securities trades, digital asset settlements, collateral movements, and general ledger postings each carry their own role separation rules. The matrix is version-controlled — every change is timestamped, attributed to the operator who made it, and retained as part of the firm's supervisory record. When a role assignment would create a conflict, the system blocks the provisioning and generates an alert before the user ever accesses a live workflow. This prevents the most common SoD failure mode in post-trade operations: a temporary override permission granted during a system migration that remains in place indefinitely, creating an undocumented accumulation of conflicting access.
Exception management with immutable override log
When a time-critical settlement requires a supervisory override of the standard maker-checker workflow, Devancore routes the override through a dedicated exception workflow. The supervisor authenticates separately, selects the business justification from a configured list, and approves within their own role scope — the system records the override with a millisecond timestamp, the approving supervisor's ID, and the business justification code. The override log is write-once: it cannot be modified or deleted by any operator, including system administrators. At period end, the override log exports directly into the FINRA Rule 3120 supervisory testing report format, giving compliance teams a complete record of every instance where the standard SoD workflow was suspended, by whom, and why.
SOX attestation, FINRA Rule 3120 annual report, and access certification
Devancore's compliance reporting module generates the access certification reviews, conflict test outputs, and annual report required for SOX Section 404 attestation and FINRA Rule 3120 compliance. The access certification workflow prompts each manager to re-attest to their team's role assignments on a configurable schedule — typically quarterly — and flags any role combination that has drifted into conflict since the previous certification. This access certification review is the primary mechanism for detecting role creep: permissions accumulated during staff transitions, M&A integrations, or temporary headcount gaps that were never revoked. Results are aggregated into a Section 404 evidence package: a documented record of every conflict test performed, every exception identified, every remediation action taken, and the management attestation that the control environment is effective. For FINRA Rule 3120 purposes, the same data set exports as the annual supervisory control report — automatically generated from the conflict matrix test results and override log — giving the CCO a pre-formatted report to present to senior management without manual assembly. For FINRA Rule 3110 supervision purposes, the same log demonstrates that supervisory procedures were adequate to detect SoD violations as they arose, not only in retrospect during examination.
Digital asset SoD — quorum policy, MPC, and cryptographically enforced maker-checker
For digital asset settlement workflows, Devancore enforces SoD at the wallet authorization level through quorum-based authorization: every digital asset movement requires approval from a designated Compliance role and a designated Operations role — not merely any two co-signers, but specifically one from each function. This quorum policy is enforced at the cryptographic level: Devancore's MPC key management distributes key shards so that the firm cannot construct a complete signing key from within a single team. The initiating operator submits the withdrawal request; the co-signing Compliance officer authenticates separately and approves within their role scope. Neither shard alone is sufficient to authorize the transaction. The authorization chain — initiator ID, role designation, co-signer ID, role designation, quorum policy version, timestamp, transaction hash — is recorded in the immutable audit log. Unlike an application-layer approval log that a privileged administrator could theoretically modify, the authorization record embedded in the transaction metadata on the Arc Network is cryptographically enforced: altering it after the fact would invalidate the transaction signature and be immediately detectable. This represents a structural SoD advantage of USDC settlement on a digital rail over legacy bank wire systems, where the approval chain exists only in a database that a rogue administrator with production access could alter. The complete authorization record — quorum policy, role assignments, approval timestamps, and transaction hash — is archived alongside the firm's traditional securities settlement records, providing a unified SoD compliance record across both asset classes.