A bank does not need to replace its core banking system to modernise AML transaction monitoring. A monitoring layer can connect to existing transaction and customer data, evaluate activity, and return or record risk decisions while the core system remains the system of record.
The quality of the result depends on the integration contract. Both teams need to agree how institutions are identified, which events are shared, when a decision is required, and what happens when either system is unavailable.
The role of the core banking system
A core banking platform manages accounts, balances, postings, transfers, and customer records. A transaction monitoring platform performs a different job. It evaluates financial activity for risk, creates alerts, supports investigations, and preserves evidence.
Keeping those responsibilities separate reduces disruption. The core continues to post and manage transactions. The monitoring layer receives a controlled data contract and responds according to the agreed operating mode.
Three common integration modes
Monitoring integrations usually fall into three patterns:
- Monitoring mode sends completed or near-complete transactions for detection and investigation
- Inline mode requests a decision before final posting and requires a strict timeout and failure policy
- Hybrid mode combines inline checks for selected scenarios with post-event monitoring and reconciliation
Monitoring mode is often the safest place to begin because teams can validate data quality and detection behaviour without affecting customer transactions. Inline decisioning should only be enabled when the core platform supports a documented pre-post callback and both parties agree what happens on timeout, retry, or service failure.
What the data contract should contain
The integration needs stable identifiers for the institution, transaction, customer, account, and beneficiary. It should also carry amount, currency, direction, channel, timestamps, narration, status, and available location or device context.
For a shared core banking provider, one provider may serve many financial institutions. Each institution must remain a separate tenant in the monitoring system. Provider credentials must not become a shortcut that mixes customer data across organisations.
Idempotency is equally important. If the same event is retried, the monitoring platform should recognise the transaction reference and avoid creating duplicate records or decisions.
Webhooks, polling, and reconciliation
A provider may deliver events through webhooks, polling APIs, or both. Signed webhooks can provide timely delivery. Polling can support recovery, historical ingestion, or providers that do not expose event callbacks.
When both paths exist, receipts and checkpoints should be reconciled. The system should know whether a polled transaction was already received through a webhook, whether a delivery remains pending, and whether an event was skipped for a documented reason.
This operational detail prevents duplicate alerts and helps support teams explain missing or delayed transactions.
How WatchTower fits beside core banking
Remllo WatchTower provides API, adapter, and CSV ingestion paths for transaction activity. It maps provider payloads into a canonical transaction model, applies configured controls, and routes relevant outcomes into alerts and cases.
The provider integration foundation supports tenant-scoped routing, connection validation, mapping previews, delivery receipts, and reconciliation patterns. Partner-specific adapters remain separate from the core monitoring logic so one integration does not distort every other customer workflow.
Where a provider has confirmed synchronous support, WatchTower can participate in inline decisioning. Monitoring and hybrid modes remain valuable when the external platform cannot safely pause a transaction.
Safe rollout without customer disruption
A phased rollout should begin with representative sandbox payloads and a documented expected outcome for each test. Teams should cover normal transfers, suspicious patterns, retries, duplicate references, malformed payloads, unavailable services, and delayed callbacks.
The next step is shadow monitoring. WatchTower evaluates live-like activity but does not change posting outcomes. Analysts compare its results with expected behaviour and tune controls.
Only after this evidence is reviewed should selected decisions move inline. Rate limits, timeouts, authentication, signature verification, IP controls, and failure behaviour must be agreed before production.
Operational ownership matters
Integration is not complete when the first transaction appears. Teams need delivery monitoring, credential rotation, provider health visibility, incident ownership, and a process for mapping changes. A changed enum or missing identifier can affect detection even when the endpoint still returns a successful status.
Banks should also decide who owns rule changes and who approves high-impact actions. Technical connectivity enables monitoring, but governance determines whether it remains safe and explainable.
Keep customer access separate from provider access
A provider integration is not a reason to give the provider unrestricted access to every institution. Provider operations, customer console access, and Remllo internal support should remain separate control planes. Each action should be authenticated, authorised, scoped to an institution, and recorded.
Credentials should be generated for the exact contract they serve, stored securely, and rotated without exposing historical secrets. Production and sandbox credentials must not be interchangeable. These boundaries make it possible to support one provider with many institutions without allowing a configuration mistake to cross tenant lines.
Modernise the monitoring layer, not the whole bank
A focused integration lets a bank improve detection and investigation while preserving its core banking investment. The practical objective is a reliable boundary: the core provides well-defined financial events, and the monitoring layer returns or records explainable risk outcomes with a complete audit trail.