The credit pipeline. The case of the MigCredit microfinance organization

How to migrate to a modern analytical platform and replace the database without stopping the work of the credit pipeline. A practical case from the leader of the microfinance market in Russia, MFO MigCredit.

MigCredit is one of the leaders of the microfinance market in Russia that specializes in issuing loans to individuals.

  • More than 950,000 loans over 7 years
  • An 18% share of the total size of the microloan market in Russia
  • 4.3 billion rubles of loans issued in 2019
  • The best company of 2018 according to [one of the largest Russian media in the banking sector]
  • First place in the overall state of the gross portfolio as of 01.07.2019 (source: Expert rating agency).

The situation before the start of the project

  • The credit pipeline was built on Deductor [the analytical platform of the previous generation from Loginom Company, released in 2004].
  • The pipeline operated as a synchronous web service.
  • The pipeline was designed for a maximum of 10,000 applications per day.
  • 9 decision-making strategies were implemented on Deductor.


  • The pipeline ran fine, but the Deductor platform was outdated [the product lifecycle was completed in 2012].
  • 12,000 applications were processed per day, exceeding the project capacity.
  • Scaling problems due to the 32-bit version of Deductor.
  • If the credit pipeline stopped, it took too long to find the reason for the failure.
  • The average processing speed of the application was 36 seconds, the maximum was 108 seconds. A faster speed wasa required.
  • Initially, the pipeline was designed for only one strategy of the decision-making system, but over time that number rose to 9. Consequently, it became more difficult to introduce changes.
  • The Deductor interface was not too user-friendly.


  1. Carry out the transition to Loginom without stopping the credit pipeline.
  2. Provide the possibility of both horizontal and vertical scaling.
  3. Perform script refactoring.
  4. Switch from Oracle DBMS to PostgreSQL.


  • The Loginom Decision Maker solution was used.
  • The asynchronous call of the decision support system was implemented immediately out of the box.
  • The format of input and output data had not changed: only the internal implementation had changed.


  • As of September 2019, the first strategy out of 9 has been implemented on Loginom, which is API-compatible with the solution that was built on Deductor. The remaining strategies continue to work on Deductor.
  • The migration of the first strategy from Deductor to Loginom took 2 months. The remaining strategies will be transferred in 2-4 weeks each.
  • The possibility of vertical scaling of capacities has appeared.
  • The transition to Loginom is combined with the change of the Oracle DBMS to PostgreSQL.
  • The transition to a modern low-code platform enables users to quickly and independently introduce changes into the work of the decision-making system without needing to involve a contractor.
  • The Loginom interface has become more intuitive, so the question of using the platform as a BI tool is being considered.

See also

Loginom 6.5.6 release note
The errors in Tree to table, Replace, Coarse сlasses, Binning, Loop handlers and in Quick view and Coarse сlasses visualizers were corrected.
Loginom 6.5.5 release note
Errors in Import from Excel file and Export to Database wizard were corrected. Chart Visualizer was corrected. The Loop Handler error was corrected.
Loginom 6.5.4 release notes
The Python operation with numexpr module was corrected in the code execution mode inside the process, errors occurring while executing requests to databases were corrected, regression bugs in...