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 (Verifia is its exclusive partner for Sri Lanka and the Maldives), 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. 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.
- Shared fraud blocklist
- Hashes only, and each company sees its own entriesCompanies can report confirmed fraud to a blocklist that every company's NIC and AML checks are screened against. Only a salted, one-way hash of the identifier is stored, never the NIC itself. A company can list and withdraw its own entries and see the size of the list, not another company's entries. When a check matches, the checking company sees the reason the reporting company wrote, so a reason should state the confirmed fraud and nothing more.
- Biometrics
- No face kept unless a client opts in, and deletable when it isA face check streams its live capture video to AWS, where we read only the verdict; no face template is kept by default. Duplicate-identity detection is off unless a client switches it on. With it on, a face template is kept for each customer who passes a certified live check, in a store belonging to that client alone, filed under a salted one-way hash rather than the NIC, and never compared across client organisations. A template is never taken from an uploaded photo. Templates are deleted on the customer's erasure request, when the client's retention policy removes the check, or when the client's store is cleared.
- Face verification
- Every check named, and no made-up verdictsA face result lists each check that ran (liveness, match, capture quality, a selfie copied from the ID, the ID photo, apparent age) and states whether it establishes that a person was present or only that a photo matched. When an image cannot be read or the face service fails, the check goes to a person for review. It does not fall back to a simulated answer.
- 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 their own link, which stops working 30 days after sending (and 30 days after completion). Their fields are stamped onto the running document and the result is re-hashed, so each signature is recorded against the exact state of the document at the moment it was applied.
- Approval on the signer's phone
Where the signer uses AnybanQID, they approve the document's hash in the AnybanQID app on their own phone, and the approval is recorded with its time. A drawn or typed signature is used only where the sender allows it, and is recorded as drawn rather than presented as equivalent. Certificate-backed signing arrives with LankaSign.
- 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.
- Legal basis
- Recognised in Sri Lankan law since 2006The Electronic Transactions Act No. 19 of 2006, amended by Act No. 25 of 2017, provides that where a law requires a signature, an electronic signature satisfies it when the method identifies the signer, shows their intention, and is as reliable as appropriate for the purpose. Section 23 excludes wills, powers of attorney, trusts, bills of exchange and contracts for the sale or conveyance of immovable property, which still need a paper signature.
- 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
- Method recorded per signerEvery signature is recorded with its method, time and the document hash, so an auditor can tell an AnybanQID approval from a drawn signature. Certificate-backed (PKI) signatures arrive with LankaSign; until then we do not describe these as certificate signatures.
- Templates
- Reusable templates and form fieldsA document sent often can be saved as a template with its signers and fields in place, then sent from the dashboard or with one API call. Fields can carry answer rules, and values can be prefilled over the API. A document sent from a template is hashed, stamped and sealed exactly as one uploaded by hand.
- 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 shows who signed, by which method and when, with the document hashes. It does not expose the document, its contents or any signer's NIC 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, and 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. An organisation can also be limited to the services its contract covers: a service outside that list is refused whatever the caller's role, API keys are offered only the scopes for services the organisation has, and someone restricted to a custom role cannot grant more access than they hold.
- 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 |
| One-time codes and confirm links | Hashes only; the code and link exist only in the message | Usable for 5 minutes |
| Face templates (opt-in only) | Template under a one-way hash, in the client's own store | Until erasure, the client's retention policy, or the store is cleared |
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.
Write to hello@clobe.lk or reach us through your account contact, who will bring in whoever needs to answer.