Holds, restrictions, and RFIs

Handle RFIs, holds, restrictions, unknown senders, and first-funding reviews without releasing blocked activity prematurely.

See API availability before implementing an API-dependent response flow in production.

How holds and restrictions work

Roots can apply controls to onboarding progression, accounts, available funds, incoming payments, outgoing payments, counterparties, products, currencies, and payment rails.

A control remains active until Roots records the required outcome. Do not release funds, retry a payment, or resume onboarding because a timer or internal deadline has passed.

stateDiagram-v2
  [*] --> RFI_CREATED
  RFI_CREATED --> RFI_SENT
  RFI_SENT --> RFI_RESPONDED
  RFI_RESPONDED --> IN_REVIEW
  IN_REVIEW --> RFI_ACCEPTED
  IN_REVIEW --> RFI_REJECTED
  RFI_ACCEPTED --> RFI_CLOSED
  RFI_REJECTED --> RFI_CLOSED

Respond to an RFI

An RFI requests information, clarification, or supporting documents. It can be linked to onboarding, an account, funds, a counterparty, or a payment.

RFI status	Meaning	Your integration behavior
`RFI_CREATED`	Roots created the request.	Create an internal case and identify the affected workflow.
`RFI_SENT`	The request is available to your platform.	Notify the responsible team and collect the requested information.
`RFI_RESPONDED`	Your platform submitted a response.	Keep the linked activity blocked while Roots reviews it.
`RFI_ACCEPTED`	Roots accepted the response.	Retrieve the linked resource again; another control can still remain active.
`RFI_REJECTED`	Roots did not accept the response.	Collect the next required information or follow the resulting outcome.
`RFI_CLOSED`	The RFI is complete.	Confirm the current account, payment, or review state before resuming activity.

First funding review

The first inbound funding event for a newly issued account can trigger a post-funding review. Roots evaluates the relevant customer information, screening results, sender information, amount, purpose, and expected activity.

sequenceDiagram
  participant Sender
  participant Roots
  participant Client as Client platform
  participant Bank as Partner bank

  Sender->>Roots: First inbound payment
  Roots->>Roots: Create post-funding review
  Roots-->>Client: Funds remain unavailable while reviewed
  alt Review requires bank decision
    Roots->>Bank: Escalate case
    Bank-->>Roots: Record decision
  end
  Roots-->>Client: Update account and funds status

For a flagged first-funding review, keep affected funds unavailable until Roots reports an authorized outcome. The target operating model requires review within 48 hours.

Unknown senders

When Roots receives an incoming payment from an unknown or unregistered sender, the planned workflow holds the payment outside the available balance and opens a compliance case.

Your platform should provide the requested sender identity, relationship, payment purpose, and supporting records. When the case remains unresolved, Roots can return the payment rather than release funds. A resolved case can still include a cooling-off period before funds become available.

Repeated unknown-sender activity can trigger an account-level review. Treat any resulting restriction as blocking until Roots reports the next state.

What to automate

Stop dependent onboarding, funding, payment, or funds-access actions.
Create an internal task with the Roots request or case ID.
Collect the requested data and documents.
Track the applicable deadline.
Retrieve the latest Roots state after each response or outcome.
Resume activity only when the current state permits it.

Next steps

Follow Respond to RFIs and understand holds for the current request schema.
Read Onboarding and review lifecycle for review outcomes.
Read Track payment status to reconcile held, settled, failed, and returned payments.