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 verificationcip:pol-tokenandcip:pol-validate— liveness validation to confirm the sender is present
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:
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:
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:
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.
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:
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.