CSV Import
How WatchTower supports institutions that cannot push transaction data into the API in real time.
Section
When CSV import is the right fit
Some institutions do not have an event-driven transaction push capability yet. For those institutions, CSV upload provides a practical first path into WatchTower while engineering maturity catches up.
- banks or fintechs with file-based operational exports
- institutions migrating from a manual or spreadsheet-heavy workflow
- pilot customers who need monitoring visibility before a proper API integration is ready
Section
Operational trade-off
CSV import supports retrospective monitoring and investigation workflows. It does not provide the same real-time interception path as live API ingestion.
How to think about it
CSV import is still useful for alerting, case generation, reporting, and analyst review. It is simply batch-oriented instead of real-time.
Section
Recommended design
- accept customer CSV files even when their source columns differ from the canonical WatchTower model
- let operators map incoming CSV columns to the required WatchTower fields during setup or import preview
- save reusable column mappings per institution or source feed
- show preview, validation, and row-level error reporting before final import
- run the same canonical normalization and rule-engine path as API ingestion
CSV import mapping flow
Customer CSV upload
|
v
Column detection and mapping step
- "txn_ref" -> paymentReference
- "debit_acct" -> sender.accountNumber
- "beneficiary_phone" -> receiver.accountNumber
- "txn_time" -> timestamp
|
v
Canonical WatchTower transaction rows
|
v
Rules engine -> decisions -> alerts/cases/import reportNext UpFirst POC Rollout
Continue Through The DocsWatchTower Integration Guides