Turning raw data into risk variables

Extraction & Transformation prepares your data for every DetectX® module. Clients, accounts and transactions come in from your data warehouse, files or API, and are mapped onto one standard model. They are then enriched and aggregated into the totals, averages and histories that monitoring and scoring rules are written against, for every client.

Request a demoAll capabilities

Where data comes in

Four ways in, each matched to how the data moves.

Payments and customer changes arrive in real time, through message queues or REST APIs. Customer, account and transaction history lands in the datamart. Sanctions and PEP lists come in through the list importer, as full loads or deltas.

Into DetectX®
From your core banking system

Message queues

Requests and responses run both ways through message queues, in real time and in batch. Payments are always checked in real time, so a payment can be stopped on a hit.

Engine
Oracle Advanced Queuing or SQL Server Service Broker
Carries
Payments, customer creations and changes
Returns
The result, back to the core

How the datamart is filled

Your data, in a structure DetectX® can read, without touching the live core.

The datamart holds the customer, account, address and transaction data DetectX® works from. Its structure is documented, so your team or a partner can fill it, usually from the data warehouse you already run.

The datamart specification · Microsoft SQL Server

The structure is documented

The datamart is a Microsoft SQL Server database with a published structure, so your team or a partner knows exactly what to fill.

  • ClientsOne record per clientName, date of birth or founding, nationality or domicile
    • AddressesLinked to a clientStreet, town, postcode, country
    • AccountsLinked to a clientAccount number, currency, opening date
      • TransactionsLinked to an accountBooking date, amount, currency, direction, counterparty

Simplified. The published specification lists every table and field, so your team or a partner fills it the same way every time.

How it gets there

A route is chosen

From your data warehouse, an operational data store or, for smaller banks, the core itself. Decided case by case during project planning.

Via your data warehouseMost common
CoreDWHDatamart

Your data warehouse, or one built for the purpose, is the source. The live core is never queried for it.

Via an operational data storeAlternative
CoreODSDatamart

An operational data store sits between the core and the datamart and feeds it.

Direct from the coreSmaller banks only
CoreDatamart

Reading core tables directly is kept to a minimum for performance, so this route suits smaller banks only.

Order of work

Parameters come first

DetectX® is parametrised before the datamart is loaded, so the first load is read the right way.

1ParametrisationSet before anything is loaded
2Datamart loadRead with the parameters in placeClientsAccountsAddressesTransactions
What goes in, and what comes next

Loaded, and it grows with you

Clients, accounts, addresses and transactions are loaded, usually from your data warehouse. As you add modules, the structure extends and new sources come in the same way.

Clients
Accounts
Addresses
Transactions
New module, new source through your warehouse

From fields to signals

Raw records in. Values a rule can judge, out.

For every run, an input query gathers what the check needs from the datamart. The Analytical Engine applies the base model, calculates values and statistics, and checks them against your business rules. Only what passes the alert filter reaches an analyst.

01

Fields and context

The input query reads the record from the datamart, with the customer’s history.

CustomerLakeside Instruments AG
Booking date14.10.2026
Amount48,500.00 CHF
DirectionOutgoing
Counterparty countryAE
History · outgoing per month, last 12
02

Values

The base model turns them into values and statistics.

Outgoing this month61,200 CHF
Monthly average, 12 months12,050 CHF
Against profile× 5.1
New counterparty countryYes
03

Signal

A business rule checks them, and the alert filter decides.

Rule · Outgoing volume above profileAlert raised · AL-BATCH-00099311Passed the alert filter → AlertViewer

Illustrative values. The same datamart structures feed MROS reporting, risk-based profiling and Digital Fingerprint.

Reading payments

Every field in the message, ready for a rule.

A payment arrives as one message, in ISO 20022 or SWIFT MT. DetectX® splits it into named fields, adds what the core system knows about the order, and derives what the message only implies, such as the country behind a BIC. Whatever the scheme, the fields a rule works with stay the same.

Incoming messagepacs.008 · ISO 20022
<Document>  <FIToFICstmrCdtTrf>    <CdtTrfTxInf>      <IntrBkSttlmAmt Ccy="CHF">48500.00</IntrBkSttlmAmt>      <Dbtr><Nm>LAKESIDE INSTRUMENTS AG</Nm></Dbtr>      <DbtrAcct><Id><IBAN>CH4400000000000123456</IBAN></Id></DbtrAcct>      <DbtrAgt><FinInstnId><BICFI>EFGHCHZZXXX</BICFI></FinInstnId></DbtrAgt>      <CdtrAgt><FinInstnId><BICFI>ABCDCHZZXXX</BICFI>        <ClrSysMmbId><ClrSysId><Cd>CHSIC</Cd></ClrSysId><MmbId>002301</MmbId></ClrSysMmbId>      </FinInstnId></CdtrAgt>      <Cdtr><Nm>BERGMANN FEINMECHANIK AG</Nm>        <PstlAdr><Ctry>CH</Ctry></PstlAdr></Cdtr>      <CdtrAcct><Id><IBAN>CH5100000000000654321</IBAN></Id></CdtrAcct>      <RmtInf><Ustrd>INV 2026-1187</Ustrd></RmtInf>    </CdtTrfTxInf>  </FIToFICstmrCdtTrf></Document>
The same fields, whatever the scheme
Debtor nameLAKESIDE INSTRUMENTS AG
Debtor accountCH4400000000000123456
Debtor agent BICEFGHCHZZXXX
Amount · Currency48,500.00 · CHF
Creditor agent BICABCDCHZZXXX
Creditor agent clearing IDCHSIC 002301
Creditor nameBERGMANN FEINMECHANIK AG
Creditor accountCH5100000000000654321
Creditor countryCH
RemittanceINV 2026-1187
Country of creditor agent BICDerivedCH
Payment systemInterfaceSIC

Core system Customer, account and order IDs are added from the core.

Illustrative payments: all names, accounts, BICs and clearing IDs are fictional. Hover any line or field to see how they match.

Explore the DetectX® Platform

Rules work with every capability.

The Extraction & Transformation decides what happens. The other capabilities give it more to decide on. Pick one to see what it does.

All capabilities

Extraction & Transformation FAQs

What compliance and IT teams usually ask before they choose Extraction & Transformation.

Something we have not covered?Talk to our team

No. Your data is mapped into the DetectX® standard model as it is, usually from the data warehouse you already run. The live core isn't queried for it.

On this pageHow the datamart is filled

Payments and client changes arrive in real time, through message queues or the REST API. The datamart is loaded on a schedule, usually overnight. Sanctions and PEP lists arrive as a full load each month, with changes in between at intervals you set.

On this pageWhere data comes in

Yes, for batch name screening. CSV files placed in an upload folder are mapped field by field to the standard client record, including which fields aren't used, and processed on schedule, usually overnight.

SolutionName Screening

Counts, sums, averages, minima and maxima per client, or per client and counterparty; the last few values; windows in days, hours, minutes or working days; and trends over a window. Each becomes a variable a rule can be written against.

PlatformBusiness Rule Engine

No. Extraction & Transformation works on structured data: records, fields and transactions. Reading unstructured text, such as news articles and register filings, is the job of Natural Language Processing.

PlatformNatural Language Processing

Prospero supplies the product, the documented datamart structure and the APIs, and sets up DetectX® before the first load. Filling the datamart is usually done by your team. Where specialist integration work is needed, Prospero works with partners.

PageOur Partners

Go Deeper

All resources
SolutionTransaction Monitoring

Where the prepared values are judged: monthly totals and ratios checked against each client's own history, with every alert traced to its rule.

See Transaction MonitoringSolutionClient Risk Scoring

The same prepared data turned into one risk score for every client, rescored as new activity comes in.

See Client Risk ScoringPlatformBusiness Rule Engine

Where rules are written against the prepared data, tested in staging and changed without a release.

See Business Rule Engine

See Extraction & Transformation in a demo

Book a working session on your own data. Bring your source systems, your field lists and your questions about mapping and aggregation.

Request a demoTalk to us