Skip to main content
Lola Send’s application layer is stateless by design. Conversation state lives in Redis, sender identity lives in backend services, and card data lives in external vaults. No persistent data resides in the application — any instance can be replaced, scaled, or restarted without data loss.

​
Stateless application design

Lola Send holds no persistent data in the application layer: This separation means the application tier is disposable. Horizontal scaling, rolling deployments, and container restarts require no data migration or state synchronization.

​
PII isolation

Sensitive personal information — phone numbers, names, addresses — is handled transiently during conversation:
  • Identity lookup — the sender’s phone number is used by PayhubAuthMiddleware to query the identity service. The returned ContextUser object is attached to the message metadata for the duration of that message’s processing.
  • Transaction composition — recipient names, addresses, and phone numbers are collected through conversation and passed to tool functions for backend validation. These values exist in the conversation context during the session.
  • No persistent PII in Redis — conversation state stores working context (current operation step, selected country, chosen recipient) but does not persist raw PII beyond the session lifecycle.
PII transits through the conversation layer during active sessions but is not persisted in application storage. The authoritative source for sender identity remains the bank’s backend identity service.

​
Card data isolation

Card data is fully isolated from the conversational layer. See PCI compliance and card security for the complete architecture. In summary:
  • Raw card data never enters the chat channel or Redis
  • Agents see only card display names (e.g., “Visa ending 1234”)
  • Card entry and tokenization occur in the external web widget
  • The backend processes tokenized references only

​
Redis data lifecycle

Redis stores two categories of data with distinct lifecycles:

​
State store

The state store holds working context for the current conversation — the operation in progress, selected parameters, and intermediate results. State is scoped to the session and is overwritten as the conversation progresses.

​
History store

The history store holds message exchanges that form the AI model’s context window. The history window is bounded by core_history_window_length, which limits how many conversation turns the model sees. Older messages rotate out as new ones arrive. Both stores use separate Redis configurations (STATE_STORE_REDIS and HISTORY_STORE_REDIS) and can be deployed on different Redis instances for isolation.

​
Encrypted transport

All communication between the chat layer and frontend web widgets is encrypted:

​
Chatwoot conversation history

When Chatwoot middleware is enabled, conversation transcripts sync to Chatwoot for human agent visibility and escalation:
  • All messages exchanged between the sender and Lola Send are mirrored to the Chatwoot conversation
  • Human agents see the full conversation history when a session is escalated
  • The bank controls Chatwoot deployment, data retention policies, and access permissions
Banks deploying Chatwoot should configure data retention policies appropriate for their regulatory requirements. Chatwoot maintains persistent conversation records that may contain PII exchanged during conversations.