Skip to main content
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.
1

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.
2

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.
3

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.
4

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:
VerdictRouting
PassedSender home agent — full conversational capabilities
PendingPending CIP agent — limited interaction, status queries only
BlockedBlocked agent — restricted to status information
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.

​
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 stateSender-facing handling
aml.needs_reviewAgent informs the sender that the operation is under review
aml.blockedAgent informs the sender that the operation cannot proceed
ClearedOperation 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 stateRouted toCapabilities
Not identifiedOnboarding agentFirst-time verification and initial remittance
Verified (passed)Sender home agentFull conversational capabilities — remittances, receipts, recipients, payment methods
BlockedBlocked agentStatus queries only — cannot initiate operations
Pending CIPPending CIP agentStatus queries only — awaiting verification result
Backend unavailableService unavailable agentInformational 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.
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.

​
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:
SystemWhat it records
Redis (history store)Conversation message exchanges for the session lifecycle
ChatwootPersistent conversation records when middleware is enabled
PayHubFull operation history — creation, status changes, completion
Callback chainTraceable 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.
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.