Integration Options
CSV and Excel Import
How WatchTower supports batch transaction monitoring, historical backfill, and file-based onboarding.
Batch monitoring
Use CSV import for historical backfill, pilots, and institutions without API push capability yet.
Reusable mappings
Map customer CSV columns into the WatchTower transaction model and reuse profiles over time.
Import controls
Inspect, validate, run, retry, cancel, and purge imports through controlled workflows.
Supported files and paired worksheets
The console supports CSV and XLSX transaction files. Map source columns, inspect the preview, and save a mapping profile for recurring files. Header recognition does not remove the need to check ambiguous mappings.
An XLSX workbook with explicitly named Sender and Receiver worksheets can be paired into one transaction per reference. Worksheet names ignore surrounding whitespace and case. Transaction Reference is preferred; Transaction No. or Transaction Number is the fallback. References are matched exactly.
- Each reference must have one sender and one receiver row. Amount, currency, Effective Date, and transaction number must agree when supplied.
- Missing counterparts, repeated references, conflicting values, ambiguous headers, unsafe numeric values, and invalid dates reject preparation.
- The paired transfer uses DEBIT from the sender perspective. Worksheet credit or debit values do not establish which party is the reporting institution’s customer.
Identity and reporting metadata
Mapped or paired party data can carry names, customer type, date of birth, phone, email, address, nationality, occupation, identification type and number, issue and expiry dates, issuing authority, BVN, and bank account details when supplied. Sender and receiver details remain separate. Supplied filing fields are available to readiness checks; missing required fields still need completion.
Store identifiers as text in Excel. Do not pad truncated account or identity numbers. Internal Account ID and Customer Effective Date are not substitutes for Bank Account Number and Account Opening Date. Unrecognized source columns can be retained as source evidence without being interpreted as regulatory fields.
Duplicates and enrichment
The import workflow detects previously uploaded file content and transaction references already present in the organization. Renaming a file does not make its contents new. Choose Skip duplicates or Block import when duplicate rows are found. Review findings before starting the run. A reference with a conflicting amount, currency, or date is rejected.
Use Fill missing reporting fields when an existing transaction needs additional supplied metadata. This fills missing fields rather than creating another transaction or replacing existing values. Use the original source label and mapping. Do not change references to bypass duplicate protection.
Historical import behavior
Read Historical Backfill for the distinction between historical context and explicit archive screening. A file import does not hold, release, or reverse a payment that has already occurred.
When CSV import is the right fit
CSV import is useful when an institution cannot yet push transactions through an API, needs to test WatchTower with historical data, or wants to backfill activity before switching to live ingestion.
It is a batch monitoring path. It can create decisions, alerts, cases, reports, and investigation context, but it is not the same as real-time inline decisioning because the transaction has already happened by the time the file is uploaded.
Good CSV import use cases
- historical backfill before a pilot
- transaction monitoring for file-based institutions
- reviewing past suspicious activity
- testing rule behavior with known samples
- migration from spreadsheet-heavy operations
- temporary fallback while API integration is being built
CSV import supports monitoring and investigations. Use API ingestion for real-time screening or inline transaction decisions.
Import workflow
- upload the CSV or XLSX file through an authenticated operator workflow
- inspect columns and sample rows
- map source columns to WatchTower transaction fields
- validate required fields, dates, amounts, and party details
- preview row-level errors before committing
- start the import run
- review import status, row counts, decisions, alerts, and errors
CSV upload
-> column inspection
-> mapping profile
-> validation preview
-> import run
-> canonical transaction rows
-> rules engine
-> decisions, alerts, cases, reportsColumn mapping
WatchTower should not require every institution to use one rigid CSV template. Operators can map source columns into the WatchTower transaction model and save reusable mapping profiles for recurring files from the same source.
Typical mappings
- transaction reference -> paymentReference
- transaction amount -> amount
- transaction date/time -> timestamp
- debit account -> sender.accountNumber
- credit account -> receiver.accountNumber
- sender name -> sender.name
- beneficiary name -> receiver.name
- channel -> channel
- narration or description -> metadata.narration
- source branch or batch ID -> metadata
Validation and row-level errors
Before a file is committed, WatchTower should make validation problems visible. This helps teams fix bad source files without creating misleading alerts from malformed data.
Common validation checks
- required field presence
- valid amount format
- valid timestamp format
- duplicate references inside the file
- missing sender or receiver details
- unsupported currency or channel values
- rows that cannot be mapped into the canonical model
Backfill and retention considerations
Backfill files can be large and may contain sensitive historical transaction data. Teams should agree the import window, expected row volume, retention expectation, and whether uploaded source payloads should be purged after processing.
Before a backfill import, confirm
- date range being imported
- expected number of rows
- whether duplicate historical records already exist
- which mapping profile should be used
- whether source payloads should be purged after processing
- who owns validation and sign-off
CSV files can contain account numbers, names, phone numbers, and transaction descriptions. Handle uploads through authenticated product workflows only and avoid sharing raw files in chat, email threads, or tickets.
Operational controls
Import runs should be observable. Operators should be able to see whether a run is queued, processing, completed, failed, canceled, retried, or purged.
Recommended rollout pattern
- start with a small sample file
- create or select a mapping profile
- validate and fix row-level errors
- run a small import
- confirm transactions, alerts, cases, and reports look correct
- increase file size or date range gradually
- purge source payloads when retention policy requires it