The customer, the owner of the Collection system, is a sizable commercial bank with a focus on lending to individuals. Therefore, debt collection management is one of the bank’s essential business operations.
It goes without saying that the bank already had a debt-management system, but by that time it became out-dated and not reliable any longer so a quick implementation of a new system was really a mission critical requirement.
As the bank had already used FICO-based solutions with satisfying results, they chose FICO as the basic technology for the debt collection automation system to be developed and implemented by an external vendor.
Our long-term cooperation was subject to our team’s successful completion of the first project stage: Business Rules Management System (FICO Blaze Advisor) implementation. Our company was well familiar with FICO and we proved to be a reliable and qualified partner, so we were proposed to develop the whole debt management system.
Thanks to the choice of the OutSystems-based FICO Application Studio and Oracle technologies, we are able to carry out the development much quicker in comparison with custom development.
Dealing with a Mid-project Change to the Architecture
Strict deadlines were the most crucial issue during the first project stage. Simultaneously with the development of the debt management system a massive architecture overhaul was taking place and this also added complexity. For a long time, the bank had been using the software architecturally based on an enterprise service bus. Its high complexity caused overspending on the implementation and testing of every single change in the requirements.
In the mid of the project we found out that before we integrate with the dialing system it should also be rebuilt using microservices approach, but the proposed plan required a lot of time for development and especially stabilisation and we realised that under such circumstances we won’t be able to meet deadlines.
Recognizing this major time constraint, our team suggested reusing the old code partially to save time while achieving the same outcome. As a result, we successfully repackaged the legacy backend into a microservice container and continued the project.
The system required a string of integrations and our senior developers handled integrations expertly and completed them smoothly. These are the software and services we successfully integrated:
- Avaya Predictive Dialing System (PDS)
A hardware-software solution for both inbound and outbound calls. The Avaya solution had already been in use at the bank when we started the project.
- Several Automated Banking Systems (ABS), ECM and CRM
This integration of the bank’s existing software was essential for seamless data exchange.
- Map and GIS services
This integration was vital for the hard collection phase when bank officers plan and organise meetings with the debtor personally.
High demands on data safety requirements were assigned to the P2P Money Transfer application. The wide functionality of the OutSystems platform enabled our specialists to:
- configure support for checking Jailbreak and Root,
- implement and correctly configure SSL-pinning,
- use the latest SDK versions (9.0) with improved security mechanisms, new API and support of new devices,
- use the AppTransportSecurity (ATS),
- implement encryption mechanisms for HTTP-connection traffic based on TLS protocol,
- configure two-factor authentication,
- use the KeyChain and KeyStore for critical data storage (login-password, credit card information, etc.),
- provide the full completion of the P2P Money Transfer app session and removal of all user data from the device,
- disable users’ critical data recording to the device log; the OutSystems platform records only data of the platform’s internal processes.
Our Business Analysts thoroughly studied the requirements and created a SRS used further for the development. Below are some functions used in different phases