Changing the aSISt obligatory reporting system to its web-based counterpart eON, to be offered as a SaaS service from the public cloud, is clearly a strategic decision. Once it has been decided, it is time for operational activities, i.e. migration of data that has been collected for years in the desktop version of the application.

The process must be carried out in accordance with applicable law, but no less important is the ease of its implementation. The specialists at FINGO wanted to make it as simple and secure as possible. Therefore, ultimately, the migration process (more commonly referred to as onboarding at FINGO) from aSISt to eON consists of 4 steps:

• Risk analysis.
• Going through the process of checking the application: its functions and security features on a test environment.
• Notifying the desire to use a cloud-based system to the supervisory authority.
• Proper data migration.

In this article, you will:

• read a description of the above-mentioned stages;
• find practical tips from FINGO's experts, who provide assistance and experience during the migration process;
• find a list of documents required by the FSA to be prepared before moving to a system based on an external cloud;
• learn what the process looks like from the customer's perspective using the example of the Co-operative Bank of Kamienna Góra.

Step 1. Risk analysis by the financial institution

Risk analysis is a comprehensive assessment process, including an analysis of the legal and technical aspects of switching to a cloud-based SaaS service. This is also the first step in the client's implementation of the eON SaaS service, which plays a key role, as the conclusions of the audit will form the basis for the preparation of the notification to the Financial Supervision Authority (step 3).

When starting a risk analysis process, a financial institution must classify the data it holds, as not all will have the same security policy requirements and generate risks at a similar level. In practice, the financial entity determines whether legally protected data, including personal data (GDPR) and data covered by banking secrecy (Banking Law) or information not covered by such strict security rules, will be entered into the new system.

The best example of a report that has lower legal requirements is fraud reporting/ fraudulent payments report. In this report, the financial institution shares aggregate data, e.g. in March there were seven fraudulent transactions totalling €300,000. Such data does not allow for identification of the user, hence the requirements for their protection are slightly lower. In practice, this means, that the handling of such data is regulated by the Banking Law.

Based on this qualification, the institution identifies and assesses the risks associated with moving to a cloud-based SaaS service. It assesses the applied security measures - whether they are sufficient to provide the required level of protection. It also determines whether the identified risks and their solutions are at an acceptable level for them.

While the financial institution may take advice from external parties in this process, it should be borne in mind that the ultimate responsibility for the risk analysis and the conduct and results of the audit rests with the financial institution and it cannot abdicate this responsibility.

Kinga Brzozowska, Information Compliance Officer at FINGO, advises on what to look out for during a risk analysis:

Risk analysis and risk auditing are processes that, according to regulatory provisions, no obliged institution can avoid. The evaluation and assessment of risks is a guarantee of the security the entity is obliged to provide to its clients. So how should a correct and legally compliant risk assessment be carried out? First of all, with full responsibility for the correctness and truthfulness of the analysis.

It is insanely important that three groups of data in particular appear in risk analyses:
1. risks that have a real impact on the entity's operations;
2. risks consistent with the facts (not underestimated, overestimated, omitted or deliberately added);
3. a clear recovery path and/or defined remedy of risks.

I am often confronted with questions and doubts as to whether it is possible to entrust the responsibility of performing a risk analysis to an external body? Absolutely not!

According to the law, the entity must perform the risk analysis on its own. Unauthorised access to internal data can lead to breaches, incidents and, in the context of risk analysis, a significant increase.

We need to remember that risk analysis is related to factors such as:
1. a high degree of confidentiality of the information disclosed;
2. revealing knowledge of internal factors influencing risks;
3. disclosure of strategies for dealing with the risks identified;
4. legal liability of the supervised entity.

Given these factors, we expect institutions in the banking sector to have a risk management or risk control department. In smaller entities, these will be teams made up of specialists: risk analysts, industry experts, compliance specialists and risk managers. These teams are responsible for carrying out risk analysis on the part of the obligated institution.

Importantly, the above obligations and responsibilities for risk analysis should not be confused with the lack of cooperation with suppliers during the analysis.

Suppliers are obliged to provide the institution with all information, cooperate openly and make the necessary documentation available in order to identify risks on their part. A credible partner recognises that it has an obligation to work with the client to identify, assess and manage risks.

Therefore, at FINGO, we guarantee assistance and collaboration with clients in a manner that complies with regulatory provisions and industry best practices.

In the case of risk auditing, the situation is somewhat different.

The audit aims to provide an independent, objective and cyclical assessment of the risk analysis process, the correctness of the identification of risks, the approach to corrective action and compliance with applicable legislation. Depending on the specific nature of the institution and the regulatory requirements, the risk evaluation audit can be carried out by an internal team, an external audit firm, a specialist risk team or a mixed approach. In conclusion, in the case of risks, a conscious and responsible approach of all participants in the process is very important.

Step 2. Going through the process of checking the application: its functions and security features (on a test environment).

The second step is to test the eON system on a test environment. FINGO Systems provides financial institutions with a test environment with test scenarios and full documentation. During the week of testing, the client's staff should go through the entire path of creating and generating reports. Thus, they verify the functions of the system, but also indirectly learn to work on a new application. If necessary, FINGO Systems' customer service department provides support, clarifying any possible doubts.

It is also possible to adapt the eON solution to the client company's internal procedures.

Bartłomiej Knapik, Release and Platform Manager at FINGO, explains the importance of testing the eON system on a test environment:

‍FINGO, as part of its contract with the client, in accordance with the supervisor's requirements, provides the financial institution with a test environment and test scenarios that the client should pass on machine-generated data. The data used for application testing must be fictitious, for formal reasons. The PFSC (PL- KNF) explicitly requires that the tests be carried out precisely on machine-generated data.

The test scenarios we provide further familiarise users with the system's functions, which is why it is so important for bank staff to go through them. Moreover, these tests guarantee the correct operation of an environment identical to the subsequent production environment.

At the end of the testing period, the client notifies the FSC that it is moving on to production and we clean up the test environment, prepare the production environment and start the technical onboarding procedure.

Step 3. Notification to the supervisory authority of the intention to change to a cloud version of the system

Most of the reports available in eON SaaS, require notification to the supervisory authorities of the transition to a cloud solution. Although only the application form needs to be submitted to the FSA, the financial institution must also draw up other documents required by the FSA when onboarding to the cloud, namely:

1. Information classification and evaluation form for the admissibility of cloud computing.
2. Risk estimation form taking into account the risks described in the cloud communication.
3. A document describing the required competencies for the use of cloud computing services.
4. Documented verification of compliance with the requirements for the contract with the cloud computing provider.
5. Documented verification of the service provider's compliance with the requirements of the PFSA cloud message.
6. Cloud computing plan.
7. A document describing how encryption keys are managed.
8. A document describing the rules for collecting logs related to the cloud computing plan.
9. Test scripts for the implementation of cloud services.
10. Exit plan.
11. Contingency plan (in the context of business continuity).

It is worth noting that the above-mentioned documents confirm that the bank has internally conducted a risk analysis and, aware of the importance of the identified risks, chooses to use the SaaS service.

If, after 14 days from the date of submission of the notification form, the supervisory authority does not object, it is a green light to move to step 4, i.e. migration of data from the aSISt system to eON SaaS.

Step 4. Migration of data from the on-premise system to the cloud

When the risk audit and the documentation required by the FSC have been completed and the supervisor has not objected, it is time to migrate the data to the eON cloud system. In the simplest terms, the bank scrapes the data from aSISta, sends it to FINGO, which uploads it to the cloud.

To ensure that the migration process runs smoothly and efficiently on the client's side (or more precisely, the IT administrator at the financial institution), FINGO's developers created a data migrator. The tool interacts with databases Oracle and Derby, on which the aSISt desktop obligatory reporting system runs. Data is downloaded, encrypted and uploaded to the cloud.

From now on, bank employees can create reports using the SaaS service.

Mariusz Zamolski, Cloud Developer at FINGO, advises on what to do before migrating data to the eON system:

Any data migration between systems is always a cumbersome and costly process. Understanding this, we tried to shorten and simplify this procedure as much as possible when moving the reporting system to the cloud. For the migration to run smoothly, it is necessary to follow two rules:

· We always carry out the migration process after upgrading to the latest version of the aSISt application.
· All aSISt application instances must be deactivated before migration can begin.

As a result (for a medium-sized institution), after about an hour one can send a file with exported and securely encrypted data for further processing on the Google Cloud side.

Dagmara Szmajdzińska, member of IT team from the Bank Spółdzielczy in Kamienna Góra, talks about the migration process from a customer perspective:

The whole implementation process was very well prepared both technically and in terms of content. FINGO provided all the documentation necessary to comply with the very restrictive provisions of the FSC's cloud communication. Dedicated personnel were appointed to the project with extensive subject matter expertise in the areas they were assigned.

The migration of data from aSISta to eOn went smoothly, the migration tools prepared by FINGO were very easy to use and the whole process took less than an hour. In addition, FINGO staff provided assistance at every stage of the implementation/migration process.

Transition from aSISt to eON SaaS - summary

Migrating data from one system to another is always challenging and costly. Therefore, when moving the reporting system to the cloud, the aim of the FINGO team was to minimise the difficulties and simplify the migration process to the absolute minimum. What's more, FINGO's project team supports the client every step of the way, so that the client feels reassured at every stage of the process.

Finally, it is also worth noting that data migration is not mandatory. Thus, the financial institution can store historical data at its premises, and start using the eON SaaS service without migrating historical data.