Transaction Ingestion
How to structure transaction payloads and how WatchTower evaluates them.
Real-time ingestion
Send transaction events with organization-scoped API keys and idempotency protection.
Detection context
Richer sender, receiver, device, and metadata fields improve monitoring and fraud-detection quality.
Operational outcomes
Every request can contribute to decisions, alerts, cases, onboarding milestones, and reporting flows.
Ingestion contract
WatchTower ingests transaction events as JSON through either the canonical transaction contract or a source-specific adapter contract. Start with a minimal useful payload, then expand as your detection model matures.
Minimum useful canonical fields
- transaction ID
- amount
- currency
- channel
- transaction type
- transaction category
- timestamp
- sender details
- receiver details
Who this supports
WatchTower is not limited to direct bank-transfer integrations. It can normalize payloads from digital banks, lenders, wallets, processors, merchant platforms, bill-payment systems, and other regulated financial operators.
Common transaction categories
- transfers
- bill payments
- airtime purchases
- merchant payments
- wallet transfers
- card payments
- cash-in and cash-out flows
Why richer payloads matter
Additional device, behavior, and metadata fields improve detection quality. If you send only a minimal payload, WatchTower still evaluates the transaction, but more advanced controls will have less context to work with.
Useful enrichment fields
- device data
- behavior counters
- account age
- geography
- metadata flags
Safe retries with idempotency
Always send an idempotency key header for ingestion requests. This protects your integration when your system retries after timeouts, network interruptions, or transient upstream errors.
What happens after ingestion
Each ingestion request returns a decision outcome with supporting context. Depending on the payload and the triggered controls, WatchTower can also create alerts, case activity, audit events, downstream operational signals, and customer context that is visible to analysts.
When the tenant is linked to Remllo Identity, investigations can also inherit onboarding-safe evidence, KYC or KYB posture, linked identifiers, and recent identity activity without exposing raw onboarding artifacts in WatchTower.
Recommended rollout pattern
- start with one institution contract
- validate one transaction category end to end
- add device information
- add behavioral counters
- add customer metadata
- add geography and corridor context
Start with a minimal working payload or an adapter-backed institution contract, then iteratively add richer context. That gets teams live quickly without blocking future signal depth.