Responsibility split

Use this responsibility split to design workflows between your platform, Roots, and the partner bank.

See API availability before relying on a workflow in production.

Workflow ownership

Your platform collects information from its end customers and submits it to Roots. Roots operates first-line platform controls. The partner bank retains final authority for decisions reserved to the bank.

flowchart LR
  Client[Client platform] -->|Data, documents, instructions| Roots[Roots controls]
  Roots -->|Status, RFI, hold, outcome| Client
  Roots -->|Escalated case or required approval| Bank[Partner bank]
  Bank -->|Decision| Roots

Responsibility matrix

Workflow	Your platform	Roots	Partner bank
Client onboarding	Submit client data, documents, and required attestations.	Validate completeness, run first-line checks, and prepare the review record.	Makes required approval, restriction, information-request, or rejection decisions.
End-customer onboarding	Submit end-customer and associated-person data and documents.	Apply requirements, orchestrate checks, manage reviews, and create RFIs or permitted controls.	Reviews and decides cases that require bank authority.
Counterparties	Provide counterparty identity and payment-destination information.	Validate data, screen the counterparty, and maintain its status.	Decides material AML or sanctions escalations.
Incoming payments	Provide payment context and respond to information requests.	Identify payment context, apply required screening and profile checks, and hold funds when required.	Decides bank-controlled exceptions and releases where required.
Outgoing payments	Submit a complete payment instruction and supporting information.	Validate preconditions, apply required screening and permitted holds, and update payment status.	Decides material sanctions, AML, and bank-controlled release outcomes.
Transaction monitoring	Provide updated customer-profile information when required.	Run or orchestrate monitoring, create cases, and apply permitted temporary controls.	Makes final suspicious-activity and material relationship decisions.

What your integration must do

Your integration must preserve identifiers and state changes across each workflow. Store Roots IDs with your own customer, account, counterparty, payment, and case references.

When Roots returns an RFI, hold, restriction, or non-terminal payment state, stop the affected automation. Route the request to a human workflow and retrieve the latest state before resuming activity.

What Roots does not do independently

Roots does not replace partner-bank final authority for decisions reserved to the bank. Roots also does not perform regulatory reporting on the bank's behalf.

Next steps

Read Compliance operating model for the decision model.
Read Holds, restrictions, and RFIs for required integration behavior.
Read Jurisdictions, rails, and scope to confirm current product boundaries.