> ## Documentation Index
> Fetch the complete documentation index at: https://docs.leapfinancial.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance integration

> How Lola Send orchestrates CIP verification, AML screening, and human escalation while the bank's compliance services retain decision authority.

Lola Send does not make compliance decisions. It orchestrates the conversational flow and routes senders based on verdicts returned by the bank's compliance services. The compliance decision authority always remains with the bank's backend systems.

## CIP (Customer Identification Program)

The onboarding agent guides first-time senders through identity verification as part of their first remittance. CIP verification happens entirely in the authenticated web widget — not in the chat channel.

<Steps>
  <Step title="Agent creates a CIP-scoped ticket">
    When the sender confirms a transaction, the agent creates a ticket with CIP-scoped allowed actions:

    * `cip:scan-id` — document scanning for identity verification
    * `cip:pol-token` and `cip:pol-validate` — liveness validation to confirm the sender is present

    The ticket also includes callback URLs (encrypted, signed, single-use) for success and failure results.
  </Step>

  <Step title="Sender completes CIP in the web widget">
    The sender opens the authenticated short link in their browser. The web widget presents the CIP flow — document capture, liveness check — within its isolated environment. No identity documents or biometric data enter the chat channel.
  </Step>

  <Step title="CIP result returned via encrypted callback">
    The widget submits the CIP result to the encrypted callback URL. The result contains the compliance verdict from the bank's CIP service.
  </Step>

  <Step title="Lola Send routes based on the verdict">
    The agent receives the callback result and routes the sender to the appropriate agent based on the compliance verdict:

    | Verdict | Routing                                                      |
    | ------- | ------------------------------------------------------------ |
    | Passed  | Sender home agent — full conversational capabilities         |
    | Pending | Pending CIP agent — limited interaction, status queries only |
    | Blocked | Blocked agent — restricted to status information             |
  </Step>
</Steps>

<Info>
  Lola Send orchestrates the CIP flow — presenting the widget, handling the callback, and routing the sender. The compliance verdict is made entirely by the bank's CIP service. Lola Send does not evaluate identity documents or make verification decisions.
</Info>

## AML screening

Automated AML screening runs as part of backend processing when operations are created. Lola Send handles the conversational layer — communicating status to the sender based on screening results.

### How screening results surface in conversation

When an operation's AML screening status changes, the agent communicates the result using pre-defined status messages that map operation states to sender-facing explanations:

| Operation state    | Sender-facing handling                                      |
| ------------------ | ----------------------------------------------------------- |
| `aml.needs_review` | Agent informs the sender that the operation is under review |
| `aml.blocked`      | Agent informs the sender that the operation cannot proceed  |
| Cleared            | Operation proceeds normally; sender receives confirmation   |

The agent does not interpret screening results or make compliance judgments. It maps backend status codes to pre-defined messages and presents them to the sender.

### Screening scope

* AML screening is triggered by the backend when an operation is created — not by Lola Send's agents
* Screening verdicts are returned as operation status fields that agents read through tool functions (`get_operations`)
* The bank's compliance team configures screening rules, thresholds, and review workflows in the backend — Lola Send has no access to screening configuration

## Agent-based routing for compliance states

The LogicRouter enforces compliance-driven routing at the middleware level. Senders are automatically directed to the appropriate agent based on their compliance status:

| Sender state        | Routed to                 | Capabilities                                                                          |
| ------------------- | ------------------------- | ------------------------------------------------------------------------------------- |
| Not identified      | Onboarding agent          | First-time verification and initial remittance                                        |
| Verified (passed)   | Sender home agent         | Full conversational capabilities — remittances, receipts, recipients, payment methods |
| Blocked             | Blocked agent             | Status queries only — cannot initiate operations                                      |
| Pending CIP         | Pending CIP agent         | Status queries only — awaiting verification result                                    |
| Backend unavailable | Service unavailable agent | Informational responses — no backend operations                                       |

This routing is enforced by the LogicRouter's selector function based on identity data injected by the authentication middleware. The sender cannot bypass, override, or influence this routing through conversation.

<Warning>
  Compliance-driven routing is enforced at the framework level, not the model level. The LogicRouter evaluates the sender's compliance status before selecting an agent. No conversational input can change the routing decision — it is determined entirely by the middleware-injected identity data.
</Warning>

## Escalation to human agents

Chatwoot integration provides a human escalation path for conversations that require manual compliance review:

* The bank defines escalation triggers — compliance edge cases, sender frustration, repeated failures, or explicit requests for human assistance
* Full conversation history is available to the human agent in Chatwoot, including authentication status and agent routing decisions
* Human agents can take over the conversation, review the compliance context, and make decisions that fall outside automated handling

## Audit trail

Lola Send maintains traceable records across multiple systems:

| System                | What it records                                                                           |
| --------------------- | ----------------------------------------------------------------------------------------- |
| Redis (history store) | Conversation message exchanges for the session lifecycle                                  |
| Chatwoot              | Persistent conversation records when middleware is enabled                                |
| PayHub                | Full operation history — creation, status changes, completion                             |
| Callback chain        | Traceable sequence: ticket creation → widget interaction → callback → operation execution |

The callback chain provides end-to-end traceability for every financial operation: the ticket records what was authorized, the callback records what was completed, and the operation records the final execution result.

<Tip>
  Banks can use the callback chain as an audit trail for regulatory reporting: every financial operation has a traceable path from conversational confirmation through widget authorization to backend execution.
</Tip>