Data protection

In short

SpeculaPro stores the most sensitive identifiers (national ID numbers such as the Ghana Card, phone numbers, email addresses and account numbers) encrypted. Someone who obtained a copy of the database would see scrambled bytes, not the numbers.

SpeculaPro still needs to answer questions like “Is this Ghana Card number on two different customers?”. So next to each encrypted value it keeps a keyed fingerprint (a blind index): matching values have matching fingerprints, but the fingerprint can’t be turned back into the number.

Only people with a specific permission can see the full values, and every such view can be audited.

What is protected

Data	Stored as
National ID (Ghana Card, passport, voter ID, driver’s licence, TIN, company registration)	Encrypted value + blind index
Phone number	Encrypted value + blind index
Email address	Encrypted value + blind index
Account and wallet identifiers	Encrypted value + blind index, plus a masked display form such as +233•••••••89 for a wallet
Counterparty identifiers	Encrypted value + blind index

Fields that rules need to compare directly (amounts, channels, countries, segments) are stored normally, so rules stay fast.

Encryption: a different key for every institution

Personal fields are encrypted with AES-256-GCM, a widely used standard that both hides the data and detects tampering.

• Per-tenant keys. Each institution’s data is encrypted with its own key, derived from the installation’s master key. One institution’s key can never decrypt another’s data.
• Bound to its place. Each encrypted value is tied to its tenant and its field. A value copied from one customer’s record into another’s, or from one institution to another, will fail to decrypt rather than silently appear in the wrong place.
• Versioned keys. Each encrypted value records which master-key version encrypted it. That makes key rotation possible: new data is written with the newest key, while older data stays readable as long as its key version is still configured.

Blind indexes: matching without revealing

Why not just store a plain hash (fingerprint) of each phone number? Because phone numbers are guessable. Ghanaian mobile numbers follow a known pattern, so there are only a few hundred million possibilities. An attacker with a database copy could hash every possible number in minutes and read off every customer’s phone number.

A blind index is a fingerprint made with a secret key (HMAC-SHA256 with a per-tenant key). Without the key, an attacker can’t compute fingerprints to compare against, so guessing is useless. With the key (inside SpeculaPro), matching works normally.

	Plain hash	Blind index
Same value gives same fingerprint	Yes	Yes (within one institution)
Can be reversed by trying all phone numbers	Yes, quickly	No, not without the secret key
Lets SpeculaPro link records (shared device, shared ID across customers)	Yes	Yes

Values are normalised before fingerprinting (for example uppercased, with separators removed), so GHA-123456789-0 and gha1234567890 match. Phone numbers are first converted to international format using your workspace’s country, so 024 412 3456 and +233 24 412 3456 produce the same fingerprint. The same applies to wallet numbers on accounts and counterparties, so a wallet written 0241234567 in one feed and +233 24 123 4567 in another is recognised as one number, and money sent to it can be traced to the account you monitor. See Customers: how phone numbers are read and Accounts: how identifiers are normalised.

What travels on the message stream

Identifiers are encrypted as they arrive, before anything is put on Kafka, so phone, wallet and account numbers on the message stream appear only as ciphertext, a fingerprint and a masked display form (such as +233•••••••56 for a wallet). SpeculaPro doesn’t keep the raw request body you sent either.

Other fields travel as you sent them: counterparty names, amounts, dates, and your own customer and account references. The same messages wait in Redis if Kafka is briefly unavailable to real-time decisions. Protect Kafka and Redis as you protect the database. See Kafka and Redis.

What reaches a trace collector

Tracing is off by default. When you switch it on, traces carry no customer names, amounts, transaction details, your customer or account references, database values, Kafka message keys or web address query strings. They do carry callers’ IP addresses (the address SpeculaPro decided on, never one a caller wrote into a header), their browser or client details, and database error messages, which can occasionally quote a value. Treat the collector like your logs: run it inside your network, restrict access, set a retention period and include it in your data protection records.

Versions before October 2026 also sent your account and customer references to the collector, as Kafka message keys. If you ran tracing on one of them and your references are phone numbers, the traces already stored hold personal data: apply your retention period to them.

Who can see full personal data

Viewing decrypted personal data needs the entities.view_pii permission. In the default roles, Senior analyst and MLRO / Compliance officer have it; Analyst does not.

The typical reason to need full values is to file a suspicious transaction report, which must identify the customer precisely. Day-to-day alert triage usually works from masked values.

Keep the circle small

Grant entities.view_pii only to people who file reports or must contact customers. Every analyst can still investigate using masked identifiers and links between records.

Retention and minimisation

• Each workspace sets its own retention. Under Privacy → Retention & legal holds, the data protection officer sets how long each kind of data is kept (transactions, customers, alerts and cases, decisions, account events, reports, the audit log, staff notifications) and whether it is deleted or pseudonymised at the end. A period can never be shorter than the legal minimum, the longest AML record-keeping period among the laws that apply (five years in Ghana). Nothing is deleted until someone has looked at a dry run and switched the purge on, and nothing under a legal hold, in an open case or covered by a report is ever purged. See Retention and legal holds.
• Operational data is cleaned up installation-wide: duplicate-protection keys for sent data (SP_WORKER_INGEST_KEY_RETENTION, 90 days), webhook delivery history (SP_WEBHOOKS_RETENTION, 30 days) and data-source file history (SP_CONNECTOR_HISTORY_RETENTION, 90 days).
• People’s rights and breaches are handled in the same Privacy area: data subject requests with their legal deadlines and the tipping-off safeguard, and a breach register with each law’s notification deadlines. See Data protection.
• Reports are kept permanently. Suspicious and cash transaction reports, the transactions they cover, and the exact goAML files exported (encrypted with the workspace’s key, with their SHA-256) can’t be deleted, filed or not. A workspace holding reports can only be removed by an operator with speculapro tenant offboard, which first exports every report and filed file for the institution to keep. See Regulatory reporting.
• Pseudonymisation (planned): SaaS institutions that want to send as little personal data as possible will be able to replace names and identifiers with pseudonyms before they reach SpeculaPro.

Keys and what self-hosters must do

A self-hosted installation needs two secrets, which you generate once:

Secret	Purpose	Rotates?
Master keys (SP_SECURITY_MASTER_KEYS)	Encrypt personal data. A list of versioned keys; the first is used for new data	Yes. Add a new version at the front and keep the old ones until all data is re-encrypted
Blind-index key (SP_SECURITY_BLIND_INDEX_KEY)	Fingerprints for matching	No. Changing it means rebuilding every fingerprint

speculapro keys generate prints a fresh pair.

Lose the keys and the data is gone

If you lose the master keys, the encrypted personal data cannot be recovered by anyone, including SpeculaPro. Store the keys in a secret manager or offline vault, with a tested backup, separately from your database backups. A database backup without its keys is unreadable; keys stored next to the backup protect nothing.

Development keys are public

In development mode SpeculaPro uses a fixed, publicly known key set so the stack starts without setup. Master keys are required outside development. Never run real data with development settings.

Related

• Security model
• Tenant isolation
• Audit log