Compliance operating model
Understand the public compliance responsibility split between your platform, Roots, and the partner bank.
Understand how Roots and its partner bank divide compliance responsibilities across the platform.
See API availability before using a compliance-dependent workflow in production.
Operating model
Roots operates first-line compliance controls for the program. Roots collects information, validates completeness, runs configured checks, manages cases and requests for information, and applies permitted platform controls.
The partner bank retains final authority for decisions reserved to the bank. Those decisions can include relationship approval, enhanced due diligence approval, sanctions outcomes, release from bank-controlled holds, material restrictions, and regulatory reporting.
sequenceDiagram
participant Client as Client platform
participant Roots as Roots
participant Bank as Partner bank
Client->>Roots: Submit onboarding or payment data
Roots->>Roots: Apply first-line controls
alt Clear and bank approval required
Roots->>Bank: Submit required approval package
Bank-->>Roots: Approve, request information, restrict, or reject
else Exception or escalation
Roots->>Bank: Escalate case and evidence
Bank-->>Roots: Record final decision where required
end
Roots-->>Client: Return status and applicable controls
Roots responsibilities
Roots provides the platform controls that support the program, including:
- Collecting customer, associated-person, counterparty, and payment information.
- Validating required fields, documents, and eligibility rules.
- Orchestrating identity verification, screening, and monitoring checks.
- Normalizing results and maintaining the Roots compliance outcome record.
- Creating RFIs, cases, holds, and permitted temporary restrictions.
- Preserving audit history and evidence references.
- Routing matters that require a partner-bank decision.
Partner-bank responsibilities
The partner bank performs independent validation and retains final decision authority where the program requires it.
| Decision area | Roots | Partner bank |
|---|---|---|
| Standard data validation and screening orchestration | Performs | Oversees the approved control framework |
| Account or product activation requiring a bank gate | Prepares and submits the record | Approves, restricts, requests information, or rejects |
| Enhanced due diligence | Collects and reviews the package | Approves when required |
| Potential sanctions matter | Holds and escalates the case | Makes the final sanctions decision |
| Release from a bank-controlled hold | Keeps the control in place | Approves release when required |
| Regulatory reporting | Preserves and escalates evidence | Determines and performs required filings |
Fail closed
Roots applies a fail-closed approach when a mandatory sanctions check cannot be completed. A payment must not proceed without the required screening.
An expired deadline, unresolved RFI, or elapsed hold period does not authorize automatic release. Keep the affected activity blocked until Roots records the required outcome.
Bank gate
A clean Roots first-line result does not by itself activate an account or product when a bank gate applies.
Before the required approval is recorded, Roots must not enable the affected account instructions, incoming funding, funds access, outgoing payments, or product capability. A new product, account type, payment rail, or higher-risk corridor can require a new gate.
Next steps
- Read Onboarding and review lifecycle to understand review outcomes.
- Read Responsibility split for workflow-level ownership.
- Read Holds, restrictions, and RFIs to handle blocked activity.
Updated about 2 months ago