Credit Bureau Integration Phase 5
The Mifos Initiative
Victor Romero
In this project I worked on updating Mifo's Credit Bureau Integration Service. A Credit Bureau is a company that collects, analyzes, and sells information about an individual's credit history to lenders and other businesses. A Credit Bureau Integration Service aims to connect Mifos to external credit bureau's api to strengthen Mifo's ability to analyze credit risk before loan officers create a loan for its clients.
This project began in 2016 by Nikhil Pawar. For this phase, I restructured the code from scratch so that the service exists outside of Apache Fineract, only relying on fineract to connect to its apis, and to fit current user needs.
- Automate the connection between Mifos and any external credit bureau api.
- Consume fineract's client api in the service.
- Create secure url headers and endpoints that connects to the external credit bureau.
- Parse the client data from fineract's client api into a request body format of the external credit bureau.
- Send client information to an external credit bureau and receive client's fico score as response.
- Complete the frontend to orchestrate the credit bureau integration and fico retrieval process.
- Map the client FICO score to the loan product.
-
Established a flexible framework for credit bureau integration: The project successfully created a foundation to connect with various external credit bureau APIs. This is achieved through a data-driven design that allows for the configuration and management of multiple credit bureaus within the system, with core entities like
CreditBureauandCBRegisterParamssupporting this extensibility. -
Consumed Fineract's client API: The service layer is capable of consuming Fineract's client API to retrieve client data. This is evident from the presence of data models like
FineractClientResponseand services designed to interact with the Fineract API. -
Implemented secure communication with external credit bureaus: The project has successfully implemented a mechanism to create secure headers and endpoints for connecting to external credit bureaus. The
SignatureServiceandSecurityTestServicedemonstrate the ability to build and send authenticated requests to a credit bureau's security test endpoint. -
Developed a data mapping mechanism: A data mapper (
ClientDataToCirculoDeCreditoRequestMapper) has been created to transform client data from Fineract's API into the specific request format required by the external credit bureau. This is a crucial step in automating the data exchange between the two systems. -
In-progress features: While the core framework is in place, the following features are still under development:
- Sending the complete client information to the external credit bureau and receiving the client's FICO score.
- The frontend to orchestrate the credit bureau integration and FICO score retrieval process.
-
Automating the creation of credit bureau.
- A credit bureau is only created when the data mappers have been created in the backend.
-
Complete implementation of non-functional requirements.
- There needs to be exception handling when resources do not exist, or if there is an internal api connection error.
-
Complete coverage of test case and use case tests.
- Currently does not have a full test coverage
-
Complete the connection to Circulo De Credito.
- Parse the FICO response to a general layout.
- Store the response in Fineract's database.
- Connect the FICO score response api to the frontend dashboard.
-
Mapping the FICO score to the Loan Product.
- When the bank officer is making a new loan product for a client, they should be able to see the score to make a decision on whether the loan should be made.
- There should first be an automated approval process, if the FICO score exceeds a benchmark point.
| No. | Method | Endpoint | Description |
|---|---|---|---|
| 1 | POST |
/credit-bureaus |
Create a Credit Bureau |
| 2 | GET |
credit-bureaus/{id}/configuration-map |
Retrieve the key and value map of api keys to connect to external credit bureau |
| 3 | GET |
/client/{clientId}/cdc-request |
Get the parsed request body for Circulo de Credito |
| No. | Method | Endpoint | Description |
|---|---|---|---|
| 1 | GET |
/client/{clientId}/ |
Get Client data from Fineract's API |
| 2 | POST |
/circulo-de-credito/security-test/{creditBureauId} |
| No. | Method | Endpoint | Description |
|---|---|---|---|
| 1 | GET |
/credit-bureaus |
Get all registered credit bureaus |
| 2 | POST |
/credit-bureaus |
Post a new credit bureau |
| 3 | GET |
/credit-bureaus/{id}/configuration-keys |
Get the configuration keys for a credit bureau |
- The user/bank officers externally register with the Credit Bureau to use their APIs (1, 2, 3)
- The user/bank officers enter the credentials (e.g. api keys) they used to register with the Credit Bureau in the Registration Portal. (4)
- The service saves the api keys (encrypted) in the database. (5, 6)
- The bank officer loads the FICO score result on the client page.
- The service decrypts the api keys, parses a request body with client info, signs the request with the keys and sends it to the external credit bureau. (7, 8, 9, 10, 11, 12, 13)
- The service retrieves the response from the external credit bureau and parses the information into a generalized FICO score. (14)
- The user/bank officer views the FICO score on the client page.
The project exhibits a Data-Driven Design, where the structure and flow of the application are heavily influenced by the data it manipulates. This is evident in several key areas:
- Core Domain Entities: The domain package houses the fundamental data entities of the application, such as
CreditBureauandCBRegisterParams. These are not just simple data holders; they are annotated with@Entityand@Table, directly mapping them to the database schema. - Data Transfer Objects (DTOs): The data package is dedicated to DTOs like
CBCreditReportData,ClientData, andCirculoDeCreditoRequest. These objects are tailored for transferring data between different layers of the application (e.g., from a service to a controller) and for standardizing the data format for API responses. This practice promotes a clear separation between the internal data representation (domain entities) and the data exposed to the client.
The project is clearly structured using the Controller, Service, Repository pattern, which promotes separation of concerns and modularity. Each layer has a distinct responsibility:
- Controller (API Layer): The api package contains the controllers, which act as the entry point for all client requests. The controllers are responsible for handling HTTP requests, deserializing request bodies into DTOs, and serializing responses. They delegate the actual business logic to the service layer.
- Service (Business Logic Layer): The service package encapsulates the core business logic of the application, including interacting with external services and orchestrating data from repositories. This layer provides a clear separation between the API and the data access layers, making the business logic more reusable and easier to test.
- Repository (Data Access Layer): The domain package also contains the repositories, such as
CreditBureauRepository.java. These repositories, which extend Spring Data JPA's JpaRepository, abstract the data access logic. They provide a simple and consistent way to perform CRUD (Create, Read, Update, Delete) operations on the database without writing boilerplate code. This layer isolates the business logic from the underlying data storage mechanism.
The project follows an API-first Design approach, similar to Apache Fineract, where the API is designed and documented before the implementation is built.
- JAX-RS Annotations: The use of JAX-RS annotations in the api package serves as a contract for the API. Annotations like
@Path,@POST,@Consumes, and@Producesdefine the API endpoints, HTTP methods, and the expected request and response formats. - Clear API Definition: The API resources, such as
CirculoDeCreditoApiResource.java, provide a clear and machine-readable definition of the API. This allows for parallel development, where frontend developers can build against the API contract while backend developers work on the implementation.
I had a great time working on this project and definitely learned alot. At first, I was initially drawn to The Mifos Initiative because I wanted to work on free and open-source technology that served underbanked communities. As I stuck around, I got more excited about it. There were many cool projects and helpful people contributing to the organization. My project introduced me to what happens behind the scenes of banking applications, including the impact they bring. I really enjoyed the fact that I had full ownership over the development of this feature. It required research about the relationships between banks and credit bureaus and how this feature will play out for users. What's more, I initially did not have experience building backend applications with Springboot, so working on this project really helped me learn alot of skills I wouldn't otherwise have the chance to learn. I will be continuing to work with Mifos after the program.
Github repository: https://github.com/openMF/mifos-x-credit-bureau-plugin
Postman: https://documenter.getpostman.com/view/19472254/2sB3QCRskT
Jira Link: https://mifosforge.jira.com/browse/MX-1
Complete functionality video: https://drive.google.com/file/d/1SqA1XOJTylZakjeBg82FZIqWQEXGOFai/view?usp=drive_link