Transaction Ingestion
How to structure transaction events, enrich them safely, and understand WatchTower decisions.
Canonical or adapter
Send the native WatchTower contract directly or let a Remllo adapter normalize your source payload.
Optional enrichment
Add device, narration, counterparty, metadata, and identity-safe context as your program matures.
Operational outcomes
Ingestion can drive decisions, alerts, cases, notifications, reporting, and analyst context.
Two ingestion paths
WatchTower accepts transaction events through either the canonical transaction API or a Remllo-provisioned adapter route. Both paths end in the same internal transaction model, rule engine, alerting, case management, and reporting workflows.
Use the canonical API when your system can emit the WatchTower transaction shape directly. Use an adapter when your upstream system has its own payload shape and Remllo needs to normalize it first.
Minimum useful transaction fields
A minimal payload should identify the transaction, describe the movement of value, and identify the sender and receiver. WatchTower can evaluate minimal payloads, but detection quality improves as more context is added.
Required or strongly recommended fields
- transaction reference or ID
- amount and currency
- transaction timestamp
- channel
- transaction type
- transaction category
- sender or customer details
- receiver or counterparty details
Useful optional enrichment
- customer ID or account ID
- counterparty account, bank, phone, or email
- device ID, IP address, user agent, and location
- session ID or request correlation ID
- narration, payment reference, or memo text
- account age, customer tenure, KYC/KYB tier, and risk flags
- metadata that preserves source-system references
Identity context is optional
Transaction monitoring does not require Remllo Identity to be enabled. WatchTower can evaluate transaction-only events and create alerts from transaction, counterparty, narration, metadata, and behavioral signals.
When Remllo Identity is connected, WatchTower can add investigation-safe customer context such as onboarding status, KYC/KYB posture, linked identifiers, device changes, profile changes, and recent account activity. Raw identity artifacts remain in Identity.
Start with transaction ingestion first. Add identity, device, and non-transactional signals over time as your monitoring program matures.
Safe retries and duplicate handling
Every ingestion request should include an idempotency key. This lets your system retry after timeouts or transient network failures without creating duplicate transaction records or duplicate alert workflows for the same logical event.
Use a new idempotency key for each logical transaction event. Reuse the same idempotency key only when retrying the same event after a transport failure.
Decision and operational outcomes
A successful ingestion request returns a decision response. Depending on the controls triggered, WatchTower may also create an alert, open or update a case, record audit activity, update reporting metrics, and add customer-level risk context for analysts.
The exact decision labels depend on the integration mode. In standard WatchTower flows, decisions map to allow, review, or block-style outcomes. The important point for implementers is that the response is immediate and the investigation workflow continues inside WatchTower.
Recommended rollout pattern
- send one validated transaction category first
- confirm the transaction appears in WatchTower
- confirm the decision response is handled by your system
- test a controlled suspicious payload
- confirm alerts, cases, notifications, and reports update correctly
- add richer optional context once the base flow is stable
Do not block launch on every optional field. A stable minimal payload with idempotency is better than a large unstable payload that changes during rollout.