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:
| Data type | Storage location | Lifecycle |
|---|
| Conversation state | Redis (state store) | Session-scoped — working context for the current conversation |
| Message history | Redis (history store) | Session-scoped — bounded by core_history_window_length |
| Sender identity | Backend identity service | Persistent — managed by the bank’s identity infrastructure |
| Card data | External card vault (VGS) | Persistent — managed by PCI-certified vault provider |
| Secrets and credentials | Doppler | Persistent — injected at container runtime |
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:
| Protection | Mechanism | Purpose |
|---|
| Payload encryption | AES | Confidentiality — callback payloads cannot be read in transit |
| Payload signing | HMAC | Integrity — tampered payloads are rejected |
| Single-use callbacks | Framework enforcement | Replay prevention — each callback URL works once |
| Time-limited callbacks | 2-hour TTL | Expiration — stale sessions cannot be resumed |
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.