There are multiple parameters to be checked before lending
It is essential to go to the grassroots to see all the possible parameters of lending. Every partner that gets integrated with Progcap has a different parameter. A response to the same query may come differently – a simple example being, someone will say 1-0, and the other will say yes-no. Someone may not be able to give a state id but will be able to provide a state name. To make this easy, a list of all the superset parameters can be created and all the new ones that get added on; the task is to make the mapper between these two sets of parameters. No matter what the API from the partner is, no matter what the response is, mapping it will be possible. For example, a state’s id is a numerical id or a text, it can be flagged in the backend and a mapper can be performed between the company’s API and the partner API.
This mapper is the fun part because every time it is performed, there are about 3 things that fall apart but the best part is only 3 instead of 97 fall apart. So every time a relationship is established, and integration is done, it is a highly customized code. The only difference is if there were 100 units of work in the first integration, it is going to probably be 50 in the second and even so less than 10 in the third integration. As long as this continues, the number of units of work can be predicted for the partner integrations that follow. Every company has a different protocol which revolves around integration. These protocols especially revolve around security in the financial industry. Some have APIs, some prefer tunnel integration, while others look at putting codes into their systems. An incredibly flexible system needs to be built to proceed at pace.
Regulations and underwriting algorithms are two different things
9 out of 10 customers wouldn’t know who their lending partners are. The interpretation of the regulation is different even though Progcap is regulatory compliant and so are its partners. Regulations are one thing while underwriting algorithms are another thing. Underwriting algorithms are primarily the logic on which lending partners approve or reject a customer’s case and this largely varies from bank to bank. Progcap largely understands how these external algorithms work along with all the algorithms that are in the system at Progcap. So when a customer comes in, it is possible to tell which is the right lending partner for a particular customer, and what is needed by the lending partner for this customer. All of these highly vary from one customer to another based on geography, size of business, amount of loan requested and so on. The beauty of this entire system is that it is a no-brainer system. One has to go by what the system says, if the loan amount is large, it will request more documents compared to a smaller loan amount request.
There is no need for a salesperson to prompt what needs to be done as the system itself gives the output. In the backend, there is a known factor that this has a 99.8% success rate. If there is a rejection, it is rejected in the first stage. But once Progcap approves a customer, it is rare that a lender will reject, i.e, barely about 1-2 a month. The customer is far away from the regulatory environment and lending partnerships. The customer is a Progcap customer not individually represented by the lending partners. It isn’t a marketplace for a customer, it isn’t complicated for them. For a seamless process, we follow standard procedures. At Progcap, the terms and conditions for all the lending partners are the same irrespective of who the customer goes to. Progcap ensures that the job of mapping the gap between the consumer and the lender is looked after, which in turn makes the entire process seamless and smooth. The customer doesn’t understand the complexity at the backend, that is the value Progcap brings in the engagement.
Authored by Richa
For more information, please reach out to the Marketing Team.
Watch the full podcast here,
