WatchTower Overview
What Remllo WatchTower does, who it is for, and how it fits into regulated financial systems.
Screen in real time
Evaluate transaction and activity events with ALLOW, REVIEW, and BLOCK-style outcomes where supported.
Investigate with context
Review alerts and cases with customer, counterparty, behavioral, identity, and analyst evidence in one workflow.
Integrate flexibly
Start with canonical API, adapter mapping, CSV import, or partner-managed ingestion depending on readiness.
Operate safely
Use roles, MFA, API key lifecycle, notifications, reports, and audit logs to run regulated workflows safely.
What WatchTower is
Remllo WatchTower is transaction monitoring, AML/fraud control, risk decisioning, alerting, and case operations in one workspace for regulated financial teams.
It receives transaction and activity events, evaluates them against monitoring controls, returns a risk outcome, and turns suspicious activity into auditable analyst work.
When Remllo Identity is connected, WatchTower can also show customer trust posture, onboarding evidence, linked identifiers, and recent identity activity beside transaction alerts and cases.
Designed for
- banks, microfinance banks, and digital banks
- fintechs, wallets, lenders, and embedded finance platforms
- payment processors, bill-payment platforms, and merchant operators
- compliance, fraud, AML, risk, and transaction monitoring teams
What teams use it for
- screen transactions before or after they complete
- detect suspicious transaction patterns and customer behavior shifts
- review alerts with customer and counterparty context
- assign, investigate, comment on, and resolve cases
- notify risk teams through in-app, email, and configured delivery channels
- produce operational reports and preserve audit trails
WatchTower is not just a transaction table. Transactions, alerts, cases, behavioral history, identity context, and analyst actions are tied back to the customer or counterparty where available.
Core platform layers
Ingestion and normalization
- organization-scoped API keys
- canonical transaction API
- source-specific adapter mapping
- CSV import and historical backfill
- idempotency protection for safe retries
Decisioning and monitoring
- ALLOW, REVIEW, and BLOCK-style outcomes
- inline decisioning for supported real-time channels
- monitoring-only ingestion for non-blocking flows
- built-in controls and custom rules
- behavioral, velocity, counterparty, value, and data-quality checks
Operations and investigations
- alert inbox
- case creation and assignment
- notes, mentions, evidence, and attachments
- AI-generated investigation summaries
- SLA tracking and status changes
Governance and security
- role-based access
- MFA and password controls
- API key lifecycle
- audit logs
- notification settings
- reports and exports
Integration modes
WatchTower supports more than one integration path so institutions can start with the option that matches their current technical readiness.
- canonical API ingestion when your backend can emit the native WatchTower transaction contract
- adapter-backed ingestion when your system has a different payload shape that Remllo normalizes
- inline decisioning when the source system can wait for an immediate risk response
- CSV import when teams need offline upload, historical testing, or backfill
- partner-managed ingestion when a shared platform routes institution traffic into separate WatchTower organizations
Inline blocking is only available where the upstream channel supports synchronous risk checks. Other channels can still be monitored through API, adapter, or CSV ingestion.
Current product capabilities
- organization-based onboarding
- API-key and adapter-backed transaction ingestion
- CSV import and backfill workflows
- real-time monitoring and inline decisioning where supported
- identity-enriched customer profiles
- alerts, cases, notes, mentions, evidence, and assignments
- rules catalog and custom rule support
- notifications across in-app, email, and configured external channels
- reporting, SLA tracking, and audit trails
- team member invites, role management, MFA, password reset, and password change
Performance and reliability
WatchTower is designed for low-latency server-side decisioning, but end-to-end response time depends on network path, source-system location, payload size, and deployment environment. Internal sandbox tests have shown server-side inline decisions in tens of milliseconds. Treat this as integration planning guidance, not a universal SLA.
Reliable integrations should plan for
- idempotency keys for retries
- duplicate reference handling
- client-side timeouts
- status query or reconciliation paths where needed
- operational review for delayed or manual decisions