Security
Security and compliance
How Dato handles personal-data parameters, keys and call logs, and what remains the caller’s responsibility.
01
Where the data comes from
Dato does not produce data; it handles access, governance and compliance. Data comes through partner data providers and public sources, and FIM is accountable to customers: one contract and one point of contact, with upstream access, credentials and changes handled by FIM.
| Data | Source | Freshness | What Dato does |
|---|---|---|---|
| Company records | Company registration records published by regulators | Within 7 days | Cached within its freshness window; repeat queries within a tenant are free |
| Identity verification | Verification channels, through partner data providers | Real time | Checked live every time, never cached; fields are not echoed, logs record them as [redacted], raw records are encrypted |
| Bank branch codes | PBOC payment system bank codes | Within 30 days | Cached within its freshness window; repeat queries within a tenant are free |
| Exchange rates | Bank of China RMB rates | Within 1 hour | The full rate table is fetched hourly and every pair is computed from it |
02
Personal-data APIs
ID card two-factor, mobile three-factor and bank card three/four-factor checks are personal-data APIs.
- Verdict only
- Results are match, mismatch or not found. No submitted field is echoed in the response.
- Redacted logs
- Call logs record the API, verdict and latency; personal fields are written as [redacted].
- Sealed audit record
- The raw call kept for audit is encrypted to the platform’s public key, so the server cannot read it. Opening one takes the offline private key, and every access is written to an append-only log.
- POST only
- Fields travel in the JSON body, out of URLs and access logs. A GET call returns 405.
- Enabled per app
- An administrator enables these APIs per app. Tenant members cannot enable them, nor re-enable an app an administrator disabled.
- Hashed in transit
- For mobile three-factor checks, all three fields are SHA-256 hashed before they reach the data source.
- Live every time
- Verification has no repeat queries; each call checks with the data source live.
03
Keys and accounts
Keys are issued per app, and an app is one environment of one calling system.
- Shown once
- A key cannot be retrieved after issue. Set an expiry from 30 days to 1 year, or none; expired keys stop working.
- Identifiable
- Keys look like dato_<app short id>_<random>, so logs show which system is calling.
- Disable to contain
- Disabling an app revokes all its keys at once. Apps cannot be deleted, so logs and bills always trace back to a source.
- Sign-in protection
- Ten failed attempts for one email from one source within 15 minutes lock sign-in temporarily. FIM opens accounts; there is no public sign-up.
04
Data and logs
What the platform stores, and how.
- Encrypted credentials
- Data source credentials are stored encrypted with AES-GCM.
- Call logs
- API, app, status, latency and credits, with params redacted per API definition, partitioned by month.
- Request IDs
- Every response has X-Request-Id, matching requestId in error bodies and the call log. Quote it when reporting an issue.
- Tenant isolation
- Tenant members see only their own tenant’s apps, usage and bills.
05
Your side
These are the caller’s responsibility.
- Consent
- Obtain the data subject’s consent before calling verification APIs.
- Your own records
- If you must keep verification records, store the requestId and verdict in your own system.
- Keys in config
- Keep keys in configuration or a secrets manager, never in the code repository.
- Separate environments
- Create separate apps for test and production so a faulty test run cannot use up the production daily limit.
Get an account and your first key
FIM opens accounts. Tell us about your company and use case, and we will set up a tenant and issue credits.