Autosave: avoid development traps in applications and save data

Surely many of you are familiar with what KYC is. For those who do not know or would like to have their memory refreshed, I will explain. KYC stands for Know Your Customer. In banking, this is the process of identifying and verifying a customer.

It is first performed at the stage of es­tablishing a relationship and renewed at specific time intervals. In practice, it is nothing else than a customer recognition and identification. This is the basis for starting a business relationship with a particular entity.

At Raiffeisen, this process is done using several tools. Customers use the eKYC application, which is part of theMyRaiffeisen.com platform. This is the point of customer contact, where there presentatives of other financial insti­tutions and corporations provide us with answers to the predefined questions concerning current business operations, organisational structure, in­ternal processes, or the precautions taken by their employers. The information gathered in eKYC, shape the knowledge necessary to begin further cooperation with individual customers.

Updating the predefined electronic form tem­plates.

As of now, there are more of them, but each one is better tailored to specific customer groups, so we expect to make the process easier and shorter.

Creating editable pdf files based on the above electronic forms, with a view of both, customers giving up the access to the platform and the employees preparing the KYC forms for them.Until now, separately maintained files in MS Word-compatible format have been the alter­ native to the platform. They were kept separate from the electronic versions. Currently, a process has been implemented for generating editable pdf files based on electronic form templates for each deployment.

Some of the data from eKYC, relevant to the Business Compliance Framework, is transfer­red to the Neuron system, where predefined indicators are calculated, based on the collec­ted data. The latter eventually go to Copernicus. This is part of the automation of customer data analysis.

In addition to these improvements, we also inten­ded to address one of the most common problems that arise when the customers fill out the forms. Many production requests, the comments du­ring UAT sessions, or other tests, regard the loss of the input data. It is not difficult to imagine the emotions of a user who provides answers to sometimes tens of questions, and then loses the whole progress in unexpected circumstances.

Each of the readers of this text surely had to deal with a similar situation at least once in their lives! It seemed to be a natural step towards meeting the users’ demands, to implement a solution that already works well in other applications in the MyRaiffeisen world, such a sePIC (Payment Infor­mation Center) and eGAO (Group Acco­unt Opening).Therefore, we started discussions to determine how to adapt autosave for eKYC.

• Risk of slowing down the application through a large number of great json structures records.
• Risk of loading the database with a large num­ber of records - currently, each data image from a manual save is maintained in the database.
• The record’s length resulting from the ope­rations associated with recording. Excessive length of this action may jeopardise the proper implementation of the records.
• Risk of two different users operating at the same time on the same form (currently, when a manu­al save is activated by one user, the other users get information about the change in the form and are forced to refresh it).
  

Before we move on to regulatory issues, it is worth noting the application's current storage of data images from individual manual saves. To our surprise, it turns out that every such action involves the creation of a so-called snapshot. The Forgotten Heroes(DaVinci) team, which has been in charge of developing and maintaining the application so far, has explained that the snapshots and the need to maintain them result from audit objectives.

At the same time, it contributed to the difficulty of introducing a simultaneous autosave. Due to that, the main purpose of dealing with the regulatory issues, was to get opinions and recommendations from various departments, in order to determine whether the logic of the existing snapshots, is something that should be maintained, and whether the idea of autosave is acceptable from various points of view.

• IT Security
• GDPR
• Compliance (teams responsible for institutional and corporate customers)
• Legal

It was logical to start with getting feedback from the representatives of the aforementioned teams on a potential change to the existing solution and the introduction of autosave in eKYC. So we’ve started a series of meetings in a smaller group of people. By persistently describing the change proposal to various people, we were able to reach positive results together.
 
In the course of discussions, it became clear that maintaining images of forms data, made from manual saves(snapshots), is not something that benefits either party. There is also no legal requirements for us to preserve records for audit purposes. It has also turned out that considering GDPR, maintaining additional sources of sensitive data without a regulatory requirement goes aga­inst the principle of data minimisation. Thanks to the confirmations which we collected through the form and email, we were able to proceed to the next stage.
 
Were turned to discussions on the technical implementation of the solution with the develop­ment teams. The course of those has unfortunate­ly proved less successful. The primary argument against changing the solution, which has been used at eKYC for years, were the high techni­cal costs. Our colleagues fromForgotten Heroes have expressed doubts about maintaining the consistency between the existing case data, for which we are using a snapshot system, and the new forms, for which we would use the autosave function which works in intervals. As one can guess, at this stage, we have already spent a great deal of time in meetings deliberating on how to prevent a recurrence of the problems that are bothering our customers. As part of discussing the results of technical discussions, we decided to reevaluate the problem. We thought...

Since the implementation of the autosave solu­tion poses a risk to the stability ofthe application and carries a high cost, our assumptions should be revised. Weasked ourselves the following questions:
Basedon the situations defined, we began to con­sider, whether we could usesolutions to help pre­vent data loss as an alternative to autosave. Goingthrough each case individually, we found that in some of them nothing could bedone (highlighted in red). For the most part, however, we were able to findalternative ways to prevent data loss.
 
The result of the discussion was isolating situations in which we can reduce thenumber of incidents without introducing autosave (highlighted in green). Oursolution was simple: instead of saving changes at intervals, we decided to usereminders for the users that if they left the site, they would lose their data.At the same time, the alerts will include the ‘return to the page’ option inorder to save the response. The alternative solution is definitely easier toimplement and carries almost no risk to the application.

The exception is when a customer is logged out due to inactivity. Then, due to the fact that the user is likely to overlook any potential warnings, we decided that if a soft logout occurs, we will use an autosave. However, this will be an isola­ted case, which generally occurs less frequently. Thus, compared to autosave in intervals, it will be used occasionally, which will eliminate the risk of overloading the application.
 
As you might have noticed, one of the situations resulting in data loss is highlighted in blue. In this case, the problem is the result of two users inte­racting at the same time, in a single eKYC form. Unfortunately, this is an example that highlights the major shortcomings of the application, which is not adapted to such circumstances. We have also started considering improvement solutions for this matter.

This proves that our discussion is still alive. Similarly, the question of abando­ning the snapshot centered architecture remains unresolved.As part of the discussion about the requirements resulting from GDPR, we learned that this is not the optimal configuration.

The above example reminded us of some impor­tant principles. First of all, the solutions that first come to mind are not always the best, despite the fact that intuitively they might seem appropria­te because they have proven effective in other applications. Secondly, in such situations, in order to break out of a stale mate, it is useful to go back to analysing the problem and trying to break it down into smaller issues needing to be addres­sed. Thirdly, application development sometimes requires knowing the opinions and expertise of many people so it is worth planning changes in great advance.