How Verifia protects the data you verify.
Written for the security reviewers who assess us before a bank, insurer or lender goes live. Every control described here is implemented in the running platform — nothing on this page is a roadmap.
Last reviewed September 2026
Cross-border
Encrypted to the bank that answers.
International checks are carried by iPiD, whose Validate API encrypts all personal data with OpenPGP or RSA. We implement the OpenPGP path. Two independent layers protect a single verification: TLS on the connection, and payload encryption inside it, addressed to the destination institution rather than to the network.
- Fetch the destination node's key
We request the public key of the validation node serving the beneficiary's BIC or country. Routing decides the key, so the payload is encrypted to the institution that will actually answer — not to a shared gateway key.
- Encrypt the beneficiary details
Name, account number or IBAN, creditor agent and any corridor-required national identifier are serialised and OpenPGP-encrypted to that node's key. The request leaving our infrastructure carries an encrypted payload and a node identifier, and nothing else that identifies the account holder.
- Validate over TLS
The call is made over HTTPS from an egress address whitelisted at the network, authenticated with our credentials and bounded by a short timeout.
- Decrypt the result locally
The match score, account status and bank resolution return encrypted to our own key and are decrypted in-process. Our private key never leaves this server — we deliberately do not use the network's decrypt utility, so no third party holds the key that opens our results.
If your standards require something else. The network supports RSA in place of OpenPGP, and bank-specific key arrangements, case by case. Tell us your requirement and we will have it configured on the corridor serving you rather than asking you to accept the default.
The verification network
So your reviewers can assess the far end of the chain, not only ours.
- Certification
- ISO/IEC 27001, certified by BSIInformation security management certification, published by iPiD.
- Scheme status
- Pay.UK Certified CoP AggregatorAccredited into the UK Confirmation of Payee scheme, and operating against FATF Recommendation 16, EU Verification of Payee and US NACHA.
- Data handling
- No-data-storage policy, decentralised routingValidations are routed to the source institution rather than answered from a pooled database of account records, and the terms permit one-time validations only.
- Deployment
- On-premise or cloud, to your policyThe validation node can be deployed in line with an institution's own security policies and data handling requirements rather than only as a hosted service.
- Encryption
- OpenPGP or RSA on all personal dataMandated by the Validate API rather than optional, with alternative or additional key arrangements supported for individual banks on request.
Sri Lanka
The person verifies themselves.
NIC, phone, bank account, face and business checks run on Sri Lankan rails. One principle holds across all of them: the person being verified acts for themselves, and the business asking for the check never handles their credentials.
- Bank account
- The customer adds their own accountWe send the customer a link; they add the account themselves and confirm ownership with a one-time code sent by their bank. The business asking for the check never sees the account credentials or the code, and never holds them on the customer's behalf.
- National identity
- Consent on the citizen's own device, before the lookupA national identity check does not run until the person has granted consent on their own device and confirmed it with a one-time code. The consent record keeps the purpose, policy version, source and IP, and can be withdrawn later.
- Identity numbers
- Encrypted, and hashed where searchedNIC numbers are encrypted at rest with AES-256-GCM. Where a lookup by number is unavoidable, only a peppered one-way hash is stored — and because the Sri Lankan NIC space is small enough to enumerate, the service refuses to start in production unless that pepper is a real secret.
- Biometrics
- Face match on a client's own opt-inFace match and duplicate-identity detection run only for clients who enable them. Comparison happens against the client's own enrolled set, and the underlying face data is not shared between client organisations.
- Documents
- Private storage, short-lived linksID photos, selfies and statements go to a private object store encrypted at rest, reachable only through signed URLs that expire. There is no permanent public address for a customer's identity document.
- Anti-phishing
- Framing denied on identity pagesThe pages that ask a citizen for identity, bank or one-time-code details refuse to be framed at all, and are served with strict transport security and no referrer leakage. Wrapping a real page in an iframe is the cheapest clone a fraudster can build; this is what stops it.
Verification is consent-first by design, under Sri Lanka’s Personal Data Protection Act No. 9 of 2022. A client cannot run an identity lookup on someone who has not agreed to it, and a withdrawal is honoured from the moment it is recorded.
Signing
A signature is worth its evidence.
Ours rests on three things: the document is hashed at every stage, the signer’s key stays on the signer’s own phone, and the completed file carries a token anyone can check.
- Hash on upload
The document is hashed with SHA-256 the moment it arrives, before anything is added to it. That hash is the baseline every later version is measured against.
- Each signer is identified, then stamps
Signers are invited individually through a single-use link. Their fields are stamped onto the running document and the result is re-hashed, so each signature is bound to the exact state of the document at the moment it was applied.
- Cryptographic signature on the signer's phone
Where the signer uses AnybanQID, the signature is produced on their own device by their private key and returned with its certificate serial — the key never reaches our servers. A drawn or typed signature is offered as the fallback where a certificate is not available, and is recorded as such rather than presented as equivalent.
- Certificate of completion
When the last signer finishes, we seal a certificate page carrying every signer, timestamp and method, plus a verification token and the final document hash. Anyone holding the document can check that token against the record and see whether the file they have is the file that was signed.
- Integrity
- Hash at every stage, published at the endSHA-256 at upload, after each signature and on the sealed certificate. The final hash is emitted on the completion webhook, so your own systems can verify a document independently of us.
- Signer identity
- Device-bound, certificate-backedAn AnybanQID signature is a PKI signature made on the signer's registered device and carries a certificate serial. The signing method is recorded per signer, so an auditor can tell a certificate-backed signature from a drawn one.
- Evidence
- Full envelope audit trailCreation, each invitation, each signature and completion are written to the tamper-evident audit log with actor and IP, and can be exported for the envelope.
- Verification
- Public token, names and timestamps onlyThe verification endpoint printed on the certificate confirms who signed and when. It does not expose the document or its contents to whoever holds the token.
Payments
We never hold a card.
Bills are paid from the customer’s bank account. The single most important fact for a reviewer is what we do not hold: no card data enters our systems, and the authority to debit an account is granted by the customer to their bank, not to us.
- Card data
- We never take card detailsPayment is taken from the customer's bank account, not a card. No card number, expiry or CVV is entered into, transmitted by or stored in our systems at any point.
- Authorisation
- The bank authorises, not usAn account is linked at the bank, and the customer proves ownership with a one-time code the bank sends them. The debit itself is executed by the bank against that authorisation — we initiate, the bank decides.
- Credentials
- Payment tokens under managed key custodyA stored payment token is a debit capability, so it is held encrypted under a managed key service whose key material never enters our infrastructure. In production the service refuses to store a token at all if that service is unavailable, rather than silently falling back to a key held on the same host as the database.
- Account details
- Alias and last four onlyBeyond the encrypted token we keep only what a person needs to recognise their own account — an alias and the last four digits. The full account number is not retained for reuse.
- Revocation
- The bank's word is finalBefore reuse, a token's validity is re-checked with the bank. If the bank says it is no longer usable, it is not reused — the customer is asked to authorise again.
- Payment pages
- Framing denied, transport pinnedPages that ask for money or one-time codes cannot be embedded in another site, and are served with strict transport security, no referrer leakage and a restrictive permissions policy.
Because no cardholder data is stored, processed or transmitted, PCI DSS scope does not arise for the payment path described here. Where a client integrates a card processor of their own, that scope stays with them and their processor.
Platform
The same floor under every module.
These apply to everything above, whichever modules a client switches on.
- Data at rest
- AES-256-GCM column encryptionIdentity and account fields are encrypted individually with an authenticated cipher and a per-value IV, tagged with the key that wrote them. A keyring retains superseded keys so rotation never strands data, and values re-encrypt to the current key on their next write.
- Secrets
- Fail-closed boot guardThe API will not start in production without its signing secrets, hash peppers and encryption key. A misconfigured deploy fails loudly rather than running on development defaults.
- Transport
- TLS throughout, hardened headersPublic traffic terminates at a reverse proxy with automatic certificate management. The application sets standard security headers and restricts cross-origin access to each client's own tenant domains.
- Sign-in
- Bcrypt, short-lived tokens, two-factorPasswords are hashed with bcrypt at cost 12. Access tokens are short-lived and signed separately from refresh tokens; refresh tokens are stored only as hashes, rotated on use and revoked on sign-out. Two-factor is RFC 6238 TOTP, verified in constant time, alongside device-bound approval through AnybanQID.
- API access
- Scoped keys, stored hashedAPI keys are generated from a cryptographic random source, shown once at creation and persisted only as a digest compared in constant time. Each key carries explicit scopes, belongs to one organisation and is revocable; a suspended organisation's keys stop working immediately.
- Authorisation
- Tenant isolation and permission gatingEvery query is scoped to the caller's organisation, and feature routes are gated on named permissions with per-organisation custom roles layered over base roles.
- Abuse control
- Rate limiting and strict validationRequests are throttled per client and tightened further on endpoints where a request is a guess at a secret. Request bodies are whitelisted and type-checked — unknown fields are rejected rather than ignored.
- Audit
- Hash-chained, tamper-evident logEach audit entry carries a hash over the previous entry and its own content, per organisation. Editing or deleting any historical record breaks the chain from that point forward and is detectable by a verification pass.
- Notifications
- Signed webhook deliveriesOutbound events are signed with an HMAC under a per-endpoint secret, so the receiving system can authenticate a payload before acting on it.
What we keep, and for how long
Verifications are one-time. Results are never used for enrichment or any secondary purpose.
| Record | Held as | Default retention |
|---|---|---|
| Verification request and outcome | Match result and status; personal fields encrypted | 7 years |
| Audit trail | Hash-chained events, actor and IP | 7 years |
| Ongoing monitoring | Screening and risk records | 7 years |
| Signed documents | Sealed file, final hash and verification token | 7 years |
| Verification links | Hash of the token only, never the token | 72 hours |
Retention is configurable per client, with a scheduled purge. An erasure request anonymises the record — personal fields are redacted while the fact and outcome of the check survive, because anti-money-laundering rules require the record to exist. Live payment credentials are the exception: those are deleted outright, never redacted. Data subjects can also export everything held about them.
This follows Sri Lanka’s Personal Data Protection Act No. 9 of 2022, and maps onto the GDPR concepts most reviewers work from: lawful basis by recorded consent, data minimisation in what we send onward, storage limitation by enforced retention, and the access and erasure rights above.
Next step
Reviewing us?
Send us your security questionnaire or data processing agreement and we will complete it against the controls above. We can also supply our egress addresses, key fingerprints and certificates for your allowlisting, and arrange direct technical contact with the verification network where a question is theirs to answer.
Reach us through your AnyBanQ contact, who will bring in whoever needs to answer.