Security and data
What we do with your data, without approximation
A compliance officer must be able to answer the supervisory authority. This page says where your data is, what YARDA keeps and does not keep, and how access is controlled and traced. It also says what does not exist yet.
Hosting
Where your data is
All of the platform’s data is hosted today in the United States, outside the WAEMU.
| Component | Provider | Location | What it holds |
|---|---|---|---|
| Database | Neon (PostgreSQL) | United States | All data: transactions, analyses, cases, reports, audit trail, accounts, trained models. |
| API and cache | Railway | United States | No lasting data: the service reads and writes in the database; the cache keeps only temporary data. |
| Console and website | Vercel | Global delivery network | No lasting data: the console queries the API. |
Database
- Provider
- · Neon (PostgreSQL)
- Location
- · United States
- What it holds
- All data: transactions, analyses, cases, reports, audit trail, accounts, trained models.
API and cache
- Provider
- · Railway
- Location
- · United States
- What it holds
- No lasting data: the service reads and writes in the database; the cache keeps only temporary data.
Console and website
- Provider
- · Vercel
- Location
- · Global delivery network
- What it holds
- No lasting data: the console queries the API.
Hosting closer to our clients, in the region or at the institution, is under study: the application needs only a PostgreSQL database, a Redis cache and a container host. Transferring data outside the WAEMU may require formalities with your data protection authority: let us discuss it before any pilot.
Your data
What YARDA keeps, and what it does not
YARDA does not need to know who your customers are to analyse their operations. Identifiers are replaced on arrival, before anything is stored, whatever the route: API, file, database, lists or screening.
Pseudonymised identifiers
Customers, phones, wallets, merchants, agents, pick-up points and devices become a keyed fingerprint (HMAC-SHA256). The key is specific to your institution: YARDA cannot recover the original identifier.
Names never kept
Names and addresses, if sent with a transaction, are not stored. Names sent for sanctions screening are compared in memory, then forgotten.
Operations kept in clear
Amount, currency, date, countries, corridor, channel, type of operation, customer due diligence tier and your transaction reference: what is needed to analyse and to report.
Ten years at least, never less
The data of your anti-money laundering duties is kept at least ten years and never deleted automatically: deleting it, once the period has passed, remains your decision.
Pseudonymised data is still personal data: pseudonymisation reduces the risk, it does not remove the obligations. YARDA processes it as your institution’s processor. Console users’ accounts (name, e-mail address) are kept in clear.
Isolation
Each institution in its own space
Your data never mixes with another operator’s, neither on screen nor in the models.
A filter applied to every query
Every read and write in the database is restricted to your institution by the data access layer itself, not screen by screen.
Pseudonyms specific to each
The same phone number gives two different pseudonyms at two institutions: nothing allows their customers to be linked.
Your models, your settings
Models trained on your data alone, and thresholds, rules, lists and policy specific to your institution.
Access
Who can do what
Rights follow each person’s role, and sensitive acts ask for one more confirmation.
Four roles
Read only, analyst, supervisor, client admin. Each role includes the rights of the one before, and the API checks every right, not only the screen.
Passwords and two-factor authentication
Twelve characters at least, stored as a bcrypt hash, attempts limited. Two-factor authentication with an app (TOTP) and backup codes, which your policy can make mandatory.
Controlled sessions
One-hour access token, session renewed for up to seven days by default, maximum length adjustable. Everyone sees their open sessions and can end them all.
A confirmation for sensitive acts
By default, exports, approving and filing a report, switching on a rule and creating a key ask the user to confirm their identity first.
API keys with limited rights
Stored as a fingerprint, shown only once, with a lifetime and chosen rights. A renewal deadline can be imposed, with a reminder.
YARDA support, visible
Every access by the YARDA team to your space is listed in the console. Your policy can make it subject to your approval, limited to 72 hours; emergency access requires a reason and alerts your administrators.
Traceability
Every act leaves a verifiable trace
What is done in YARDA is recorded as it is done, and the record cannot be altered.
A chained audit trail
Each entry carries the SHA-256 fingerprint of the one before and is written in the same transaction as the act. The database refuses any change to or deletion of an entry.
Sealed reports
A filed report is frozen and its fingerprint shown; the console checks that the stored copy has not changed.
Verified models
Every model is checked against its SHA-256 fingerprint when it is loaded: an altered file is refused.
Encrypted secrets
Traffic goes over HTTPS. Two-factor secrets, connector passwords and keys handed over by link are encrypted, each with its own key.
Subprocessors
The providers involved
Strictly for the needs of the service, as our privacy policy describes.
Neon
PostgreSQL database, United States, encrypted at rest by the host.
Railway
Hosting of the API and the cache, United States.
Vercel
Hosting of the website and the console.
Resend
The console’s e-mails: invitations, resets, notices. Receives the recipient’s address.
Comet ML
Registry for part of each client’s AI models.
A security questionnaire to fill in?
Send it to us: we answer it point by point, as frankly as this page.