Data ownership and ingestion
Ce contenu n’est pas encore disponible dans votre langue.
In short
Section titled “In short”SpeculaPro keeps its own copy of the transactions, customers and accounts it monitors. Your systems send the data to SpeculaPro, and SpeculaPro never reaches into your core banking or wallet database to look things up.
An analogy: an auditor who keeps photocopies of every invoice they checked can prove what they saw, even if someone later edits the original. An auditor who only ever looked at the live ledger cannot. SpeculaPro is the first kind.
Your systems SpeculaPro┌───────────────┐ push a copy ┌──────────────────────┐│ Core banking │ ──────────────▶ │ Its own copy, in one ││ Wallet ledger │ │ standard format, ││ Card switch │ │ kept as evidence │└───────────────┘ └──────────────────────┘ ▲ │ └───────── never queried ───────────┘Why SpeculaPro works this way
Section titled “Why SpeculaPro works this way”Speed. Anti-money-laundering rules look at 30 to 180 days of a customer’s history. Running that query against your core banking system for every single payment would be far too slow at thousands of transactions per second, and it would slow down your own production systems.
Evidence. When a regulator asks why a case was raised, you must show exactly what data the rule saw at that moment. If your source record has since been corrected or deleted, SpeculaPro’s stored copy is the evidence.
One format for everyone. Every institution’s database looks different. SpeculaPro converts what you send into one canonical (standard) model, which is why the same rule library works for a mobile money operator and a bank.
Availability and security. If your database is slow or down, monitoring carries on. And you never hand a vendor credentials to your production database.
How data gets in
Section titled “How data gets in”You can use one way or several. Whatever the route, everything is converted into the same standard events and placed on the internal message stream.
| Route | Best for | How it works |
|---|---|---|
| Decision API (real-time) | Fraud checks before a payment is approved | Your payment system calls SpeculaPro and waits for allow, step_up, review or block. The transaction is stored and monitored post-event as well. Available now. |
| Ingest API (after the fact) | Most AML monitoring; customer and account updates; exchange rates; account events | Your system posts transactions, customers, accounts, FX rates and account events (logins, failed OTPs, SIM swaps, profile changes) in batches of up to 500. No need to wait for a decision. Available now: see Sending data. |
| Kafka or Redpanda topic | High volumes, often self-hosted | Your systems publish one item per record onto your own topic; the connector role reads it, dead-letters what fails the checks, and commits only what is safely handled. Available now: see Kafka topics. |
| File drop (SFTP, S3) | Banks starting out; end-of-day extracts | The connector role collects CSV, JSON Lines and ISO 20022 (camt.053, pain.001) files from your SFTP server or bucket on a schedule, loads each once, and writes a results file back. Available now: see File drops. |
| File upload | Pilots and backfills | An administrator uploads CSV or JSON under Settings → Data import. Available now: see Importing a file. |
| Change data capture | Institutions that cannot change their systems to push data | The connector role follows your core-banking database’s changes, either as Debezium change events on Kafka topics or directly through Postgres logical replication, and a versioned mapping turns each table’s rows into transactions, customers, accounts or account events. Deletes become status changes; transactions are kept. It is still a feed into SpeculaPro’s copy, not a live query. Available now: see Change data capture. |
Sending the same thing twice is safe
Section titled “Sending the same thing twice is safe”Networks fail and systems retry. SpeculaPro recognises each record by your own identifier for it (the external_id) within your workspace. If the same transaction arrives twice, the second copy is reported as a duplicate and nothing is counted twice: a retried GHS 5,000 deposit will not suddenly look like GHS 10,000.
If the same external_id arrives with different details, it is rejected rather than silently overwriting the first one. The protection lasts as long as the idempotency keys are kept (90 days by default); see Idempotency and retries.
Updates that arrive out of order
Section titled “Updates that arrive out of order”Customer and account updates can carry a version from your system. An update with a version is applied only if that version is higher than the one already stored; an equal or lower one is reported as stale and ignored. So if an older update arrives after a newer one (for example after a retry), SpeculaPro keeps the newer data, and resending the same update is harmless. An update without a version is always applied. Each update is a complete snapshot of the record: fields left out are cleared. See Versions.
Transactions that arrive before their customer
Section titled “Transactions that arrive before their customer”Transactions often arrive before the customer or account feed has caught up. SpeculaPro does not reject them. It creates a placeholder (a “stub”) for the unknown customer or account, and the first real customer or account record you send replaces it. Until then the placeholder has no details, so rules that need customer information (segment, KYC tier, risk rating) can’t use them yet. Send customers and accounts first where you can.
What is stored
Section titled “What is stored”| What | Examples |
|---|---|
| Customers | Individual or business, segment, risk rating, KYC tier, country, declared monthly volume |
| Accounts | Bank account, wallet, card, merchant or agent account; currency; status |
| Counterparties | The person or business on the other side of a payment |
| Transactions | Amount, currency, channel (mobile money, card, transfer, cash, agent…), direction, country |
| Devices and sessions | Phone or browser fingerprints used for fraud rules |
| Risk designations | PEP, sanctioned, high-risk and similar flags. See Risk designations. |
Every record keeps two layers:
- Canonical fields: the standard columns that rules use, such as amount, channel and country, plus the converted amount in your base currency and the exchange rate used.
- Custom fields: extra attributes you define (for example
loyalty_tier), which rules can also use.
How the data is protected
Section titled “How the data is protected”- Field-level encryption for personal data such as ID numbers, phone numbers, emails and account identifiers, applied as the data arrives. See Data protection.
- Retention: each workspace sets how long each kind of data is kept, never below the AML minimum, with legal holds; the worker’s purge deletes or pseudonymises what is past its period, and drops whole monthly partitions when every row in them may go. See Retention and legal holds.
- Optional pseudonymisation of names and identifiers for SaaS customers who want to send as little personal data as possible (planned).
- An access audit log that records who looked at what. See Audit log.
What this means for you
Section titled “What this means for you”- Compliance: SpeculaPro’s copy is your evidence of what each rule saw. Treat it as a record, not a cache.
- Integration teams: pick the route that suits each system. Most institutions start with the ingest API (or a file upload for a pilot) and add the decision API for real-time fraud later. Start with Sending data.
- Data protection officers: SpeculaPro holds personal data. Choose self-hosting or a SaaS region that meets your residency requirements.