RemlloDocs
Book demo
OverviewCore ConceptsIntegration OptionsAPI ReferenceOperationsSecurityGo-Live
DocsWatchTowerCSV Import

CSV 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.

Section

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
Batch, not inline

CSV import supports monitoring and investigations. Use API ingestion for real-time screening or inline transaction decisions.

Section

Import workflow

  1. upload the CSV file through an authenticated operator workflow
  2. inspect columns and sample rows
  3. map source columns to WatchTower transaction fields
  4. validate required fields, dates, amounts, and party details
  5. preview row-level errors before committing
  6. start the import run
  7. review import status, row counts, decisions, alerts, and errors
CSV import flow
CSV upload
  -> column inspection
  -> mapping profile
  -> validation preview
  -> import run
  -> canonical transaction rows
  -> rules engine
  -> decisions, alerts, cases, reports
Section

Column 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 -> reference
  • 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 -> narration
  • source branch or batch ID -> metadata
Section

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
Section

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
Sensitive data handling

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.

Section

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.

Useful API areas
GET /api/v1/transactions/imports/mapping-profiles
POST /api/v1/transactions/imports/inspect
POST /api/v1/transactions/imports/validate
POST /api/v1/transactions/imports/runs
GET /api/v1/transactions/imports
GET /api/v1/transactions/imports/{id}
POST /api/v1/transactions/imports/{id}/retry
POST /api/v1/transactions/imports/{id}/cancel
POST /api/v1/transactions/imports/{id}/purge-payload
Next UpFirst POC Rollout