Every regulated product in Sri Lanka eventually needs the same thing: confidence that a customer is who they claim to be. Most teams solve the checking and skip the proving. VerifiaOS is built around the assumption that someone will one day ask you to justify every lookup you ever ran.
Consent before the check, not after
Under the Personal Data Protection Act, querying a government register about a person is processing their personal data and needs a lawful basis. In VerifiaOS that basis is a record, not a checkbox.
Before a NIC verification runs, the subject receives a one-time link by SMS or email. It states plainly what will be checked, by whom and why. When they grant consent, the platform stores the timestamp, purpose, mechanism and originating address. The verification endpoint will not execute without a matching, unexpired consent record — not "should not", cannot.
Encryption that assumes the database leaks
A verified NIC is a national identifier tied to a real person. VerifiaOS encrypts identifiers and financial data at rest with AES-256-GCM under a rotatable keyring, so a key can be retired without re-encrypting history or losing access to old records.
Because encrypted values can't be searched, lookups go through a peppered blind index — a keyed hash that allows exact-match queries without the plaintext ever being present. Nothing sensitive reaches application logs, error traces or analytics.
Audit logs you can actually rely on
- Every verification, consent grant and administrative action is recorded
- Entries are hash-chained, so removing or editing one breaks the chain visibly
- Access is scoped by role — a merchant sees their own activity and nothing else
- Administrative accounts require time-based one-time passwords, with lockout after repeated failures
The point of the chain isn't cryptographic theatre. It means that when an auditor asks whether the log could have been quietly edited, the answer is demonstrable rather than a matter of trust.
Bank account verification
Identity and banking are separate proofs. VerifiaOS verifies that an account exists and belongs to the verified individual by checking with the bank directly, so a merchant isn't paying out to an account that merely has a matching name typed into a form.
Roles, and the principle of least surprise
Not everyone who touches a verification platform should see everything in it. VerifiaOS separates platform administrators from tenant administrators from merchants, and a merchant role that only needs to raise bills does not get access to verification results.
This matters more than it sounds. The most common cause of a data incident is not an attacker — it is an internal account with more access than its job required, used carelessly.
Working with bank integrations that were not designed for you
Bank APIs in this market are built for the bank's own channels first. Header requirements are undocumented, error codes overlap, and a firewall rule can change on a Tuesday and start rejecting requests that worked on Monday.
The practical consequence is that a verification platform has to be defensive by default: treat every upstream as capable of returning something unexpected, distinguish a genuine decline from a transport failure, and never surface a raw bank error to an end user who cannot act on it.
A customer should never be shown a raw upstream error code. They should be told what happened and what to do next.
Retention, and deleting on purpose
The PDPA expects personal data not to be kept indefinitely. In practice that means a scheduled job that finds expired records and removes or irreversibly anonymises them, plus a report proving it ran. Retention written into a policy document and not into a schedule is not retention.
What it doesn't do
VerifiaOS does not make the compliance decision for you. It gives you a verified result, a consent record, an encrypted store and a tamper-evident trail. Whether that satisfies your regulator, and what you do with a partial match, remains your policy — as it should be.
