Draft. This article is a proposed piece for your Resources section. It is general information, not legal advice; have your compliance team review before publishing.
What the rules ask of you
Sri Lanka’s Customer Due Diligence Rules, issued in 2016 under the Financial Transactions Reporting Act, set out what a financial institution must do before and during a customer relationship. Stripped of the legal drafting, the obligations fall into a few familiar groups: identify the customer and verify that identity against reliable documents; understand the purpose of the relationship and, where relevant, the source of funds; keep monitoring as the relationship continues; and keep records that let a supervisor reconstruct what was done, by whom, and on what basis.
None of this is new to an onboarding desk. What has changed is the volume, and the temptation to let software fill the gaps quietly. The rules do not care whether a field was typed by an officer or extracted by a model. They care that the institution can stand behind it.
What an assistant may do
Quite a lot, in our reading. An assistant can request the right document at the right step, read it, compare the name on a utility bill with the name on an identity card, check that the bill is recent enough, and lay out what it found for the officer. It can translate a Sinhala or Tamil identity card into English. It can keep the interview on track and refuse to be pulled off task. All of that is collection and preparation: work the rules expect to be done well, but do not require a human to do by hand.
The rules do not care whether a field was typed or extracted. They care that the institution can stand behind it.
Where it must stop
At the decision. Verification is a judgement that the institution makes, and a person must own it. In practice this means three design rules. First, no value becomes part of the customer record until a named officer confirms it, including translations. Second, when the assistant is not sure, it must say so rather than guess: a low-confidence extraction is presented as “please enter this”, not as a fact. Third, the assistant does not approve, decline or push anything to core banking; it prepares, and the officer acts.
There is a fourth, less obvious rule: the assistant must refuse bad evidence. A blurred identity card that is “probably fine” is not fine. Rejecting it with a specific reason costs a minute at the counter; accepting it costs the institution the ability to stand behind the record.
Designing the record
Record-keeping is where AI-assisted onboarding can be better than the paper process it replaces, if the record is designed for it. Every extraction should carry its source document and its confidence. Every rejection should carry its reason. Every confirmation should carry the officer’s name and the time. And the conversation itself should be kept, because a supervisor who can read the interview can see exactly how a value came to be recorded.
A checklist for your compliance team
✓Can any field reach the customer record without a named officer’s confirmation?
✓What happens to a low-confidence extraction: is it shown as a fact or as a request?
✓Does every rejection state a reason the officer can act on?
✓Is the translation of a Sinhala or Tamil document confirmed before it is recorded?
✓Can you export, for one case, the documents, the extractions, the rejections and the confirmations, with names and times?
✓Where is the data stored, for how long, and who can delete it?
If your answers are not the ones you would want to give a supervisor, that is a design problem, not a compliance problem, and it is fixable. Talk to us →