Skip to content
WICSWATCHLIST INTELLIGENCE& COMPLIANCE SCREENING
Platform & Deployment

Deployment-neutral by design. Scaled by adding pods.

The same platform runs a start-up’s onboarding flow and a Tier-1 bank’s payment rails. Run it on your Kubernetes, in our cloud, or across both — and grow by adding pods, not by re-platforming.

Book a demoSee the version vector

Every decision carries a 7-part version vector, so any outcome can be replayed for auditors and examiners.

Cluster viewLive

Load64%

Throughput

2,029

req/s

p99 latency

175 ms

250

CoreModular monolith

  • List management
  • Alert & case workflow
  • Audit & version store
  • Profiles, rules & config
  • REST / SOAP APIs
PostgreSQLRow-level security
Versioned work

Screening engineStateless · no database

6/10

Pinned list version2026.10.13-02

Batch workersQueue-driven

1/6
Queue

0 records

Live architecture: a modular core with its database, stateless screening engine pods and queue-driven batch workers that scale out and in with the load.
09:41:07Engine pods scaled out5 → 6

Illustrative — invented names and figures.

Deployment

Your infrastructure, your choice.

Three ways to run WICS. The same images, the same audit trail and the same APIs in each.

Your data centreDataCoreEngine

Kubernetes on-prem

Inside your data centre, under your controls. Nothing leaves the bank.

  • Lists, cases and audit trail stay in your network
  • Runs on your own Kubernetes cluster
  • You decide when to upgrade
Your bank
CloudCoreEngineData

Cloud SaaS

Operated by us, sized to your volumes, upgraded without disruption.

  • No servers for your team to run
  • Capacity sized to your volumes
  • New versions rolled out for you
Your data centreDataCore
CloudEngine

Hybrid

Governance on-prem, elastic engine capacity in the cloud — or the other way round.

  • Core and data on your premises
  • Engine pods added in the cloud at peaks
  • The engine has no database of its own

The same in all three

  • Versioned container images
  • 7-part version vector
  • REST · SOAP · MQ · Kafka · SFTP
  • One audit trail
  • English · French · Arabic
Reproducibility

Seven versions on every decision. Any decision, replayed.

Every decision records the exact artifacts that produced it. Replay any historical outcome for auditors, examiners and model-risk reviews — and get the same answer.

  • Input hash: proof of exactly what was screened
  • List, engine, profile, configuration, rule and model versions pinned
  • A replay runs the same versions and returns the same output
  • 100% decision reproducibility
A decision record receiving its seven version stamps, then replayed with the same versions to give an identical result.

Decision record

D-20261013-004182

MT103Northwind Trading LLC184 ms
pinned
  1. 01Input hashsha256:9f3a…c41e
  2. 02List version2026.10.13-02
  3. 03Engine version4.2.1
  4. 04Profile versionrt-payments@7
  5. 05Config versioncfg-118
  6. 06Rule versionrules-62
  7. 07Model versionfp-reducer@0.9.3

Stamping the version vector…

Original

Held for review0.87

Output hash

sha256:41be…07d9

Replay

Execution flow

From request to explained decision in five stages.

Every channel runs through the same flow. A name screened in a payment, a batch file or an analyst search is resolved, scored and recorded the same way.

  1. 01

    Request

    A SWIFT MT or MX message, XML payload, onboarding call or batch record arrives and is parsed through its configured mapping.

    SWIFT MT / MXXMLMapping

  2. 02

    Canonical format

    Parties and fields are extracted into one canonical model, then normalised, script-detected and transliterated.

    NFKCScripts

  3. 03

    Candidate generation

    The engine narrows millions of list entities to a small candidate set drawn from the pinned list version.

    Pinned listsStateless

  4. 04

    Staged matching

    Candidates pass progressively more precise stages, ending in Damerau-Levenshtein scoring and rule evaluation.

    Damerau-LevenshteinRules

  5. 05

    Decision & explanation

    The decision returns with its TreeSHAP explanation and the full version vector, written to the immutable audit trail.

    TreeSHAPVersion vector

Every decision ships with its own evidence.

Stage five returns more than a verdict. The record binds the outcome to its explanation and to the exact version of everything involved.

  • Deterministic replay from the version vector
  • Feature-level TreeSHAP attributions for analysts
  • A person decides every escalated match
Decision record200 OK
{
  "decision": "HOLD_FOR_REVIEW",
  "latency_ms": 184,
  "top_match": { "list": "SANCTIONS", "score": 0.87 },
  "explanation": [
    { "feature": "name_similarity", "shap": 0.31 },
    { "feature": "translit_variant", "shap": 0.12 },
    { "feature": "dob_absent", "shap": -0.05 }
  ],
  "version_vector": {
    "input_hash": "sha256:9f3a…c41e",
    "list_version": "2026.10.13-02",
    "engine_version": "4.2.1",
    "profile_version": "rt-payments@7",
    "config_version": "cfg-118",
    "rule_version": "rules-62",
    "model_version": "fp-reducer@0.9.3"
  }
}
Integration

Every way in. Every way back.

REST, SOAP, IBM MQ, Kafka, SFTP and watched folders — in both directions. Each message gets an acknowledgement at once and a final answer when it is decided.

Six channels around WICS: REST, SOAP, IBM MQ, Kafka, SFTP and watched folders. Requests come in, an ACK goes back at once, then the final answer. A failed answer is retried, then parked as NACK.
REST API
SOAP
IBM MQ
Kafka
SFTP
Watched folder
WICSScreening & deliveryGetStatus
Dead-letter0

Any channel in, any channel out

A request and its answer can travel on different channels: in by IBM MQ, answered by a REST callback.

An answer, always

An ACK on receipt, a final answer after the decision. Failed callbacks are retried automatically, then parked as NACK for an operator. GetStatus tells you where any message is.

Secured per channel

API keys per channel with scopes, an IP allow-list and optional HMAC-SHA256 signatures. SFTP pins the host key. Secrets are stored encrypted.

Formats

Payments

  • Any SWIFT MT
  • MT103
  • MT202 COV
  • ISO 20022 MX
  • pacs.008
  • pacs.009
  • pain.001
  • camt.056
  • ACH

Files & payloads

  • XML
  • CSV
  • Excel

Headers

  • Request headers per bank
  • Response headers per bank
Service levels

Under 250 ms in flight. Millions of records overnight.

Payments are screened before funds move. Overnight batches screen whole portfolios against every list. Engine pods and batch workers scale on their own, so one never slows the other.

p99 latency
<250ms
Real-time transaction screening
Records in 4 hours
3M+
Overnight batch screening
List entities
5M+
Screened against in that batch
Decision reproducibility
100%
Every decision can be replayed
Operations

Simple to install, check and upgrade.

WICS ships as versioned container images with an install package. Each service reports its version and its health.

  • Versioned container images; each service reports its version
  • An install package with a backup script and a readme
  • Health checks on every service
  • PostgreSQL with row-level security for each bank
  • The engine is a separate component with a versioned contract
  • English, French and Arabic, business calendars, units and a time zone per company
Every service reports its image version and passes a health check in turn.

ServicesHealth checks

All healthy7/7
ImageVersionHealth
  • wics/user-management3.2.0Checking
  • wics/list-management3.2.0Healthy
  • wics/screening3.2.0Healthy
  • wics/case-workflow3.2.0Healthy
  • wics/notifications3.2.0Healthy
  • wics/batch-worker3.2.0Healthy
  • engine/screening4.2.1Healthy
Backup scriptIn the install package
Row-level securityOn, for each bank
Engine contractVersioned
Illustrative — invented names and figures.

Keep exploring