All About Our SDK FAQ
View FAQ OverviewOur scoring solution utilises a proprietary Mobile App, CredoApp, developed to enable the launch of a digital scorecard. The app is used during the loan or credit card application process and provides CredoLab with a snapshot of the customer’s digital footprint. In combination with the bank's performance data, this enables the development of robust Big Data-based highly predictive scorecards that enhance the lenders' credit decisioning process.
A simple plug and play data collection and credit scoring tool offered by CredoLab that can be easily integrated into your existing mobile application. Flexible APIs ensure that our scoring technology easily integrates with your existing IT infrastructure. CredoSDK enables companies to get started with AI credit scoring quickly with little hassle.
We collect data permissions from 8 main, broad categories-- Apps, messages, contacts, image and audio files, emails, calendars and downloads. We allow the customer to control which permissions they want to allow, and which they’d like to decline access to.
We can develop scorecards for all unsecured lending products including credit cards, personal loans, POS loan, payday loans, two-wheeler loans and auto loans. Our scorecards are effective with all user segments including new-to-bank and new-to-credit customers, and also to cross-sell to existing customers in developed and developing countries.
CredoLab has a wide ranging network that includes banks, consumer finance companies, auto lenders, online and mobile lenders, insurance companies and retailers. As a CredoLab partner, you will be in contact with an audience highly receptive to your offerings and business model. Read more on how the partnership will benefit your business here.
This is a no-fuss, simple plug-and-play digital scoring tool. This product is highly recommended for businesses who already have an existing app with a substantial active client base. Our flexible APIs ensure that our scoring technology easily integrates with your existing infrastructure. CredoSDK enables companies like yours to get started with AI credit scoring quickly with increasing approval rates, while keeping your risk under control and start accepting more customers with CredoSDK. Find out more here.
CredoLab's scoring algorithm collects millions of data points on average from the smartphone device. The number of data points collected depends on the permissions granted, the operating system (Android, iOS) and its version, and the actual usage of the mobile device. In any case, the more permissions granted, the more accurate the score, the higher your chances of getting a better score.
We offer three scorecard integration options: merge, dual, and input.
- Merge: you can merge your existing scorecard with a CredoLab digital scorecard to create a more powerful, enhanced score.
- Dual: you can run the CredoLab digital scorecard in parallel with your existing scorecard to assist in your decision making.
- Input: you can use the CredoLab digital score as one additional characteristic in your existing scorecard.
Currently we have three kinds of partnership options available to you.
- Data partnership
- Co-innovation partnership
- Technology partnership
Visit our partner page to know more on each of these options.
Our standard SLA with most clients is no more than 1 minute but 97% of our transaction records show is less than a second for our clients to see the results.
Credolab agrees, represents, and warrants to provide the Client with quality support and access to knowledgeable personnel at all times. CredoLab provides a multi-level support to the Client executed by the both Customer Success Manager and the Technical Support team. Incoming requests are prioritized according to its scale and duration of impact on production:
- Level 1, Customer support (General requests, minor issues. This is a transitional level for incoming requests).
- Level 2, Technical Support (Minor issues with high priority).
- Level 3, Technical Support (Major Issues).
The actual size would depend on the number of permissions your app is allowed to collect. On average, the SDK is about 250kb big and can be operated on both operating systems (iOS and Android).
The process is completed faster than you can say "CredoLab". The app begins accessing data only after the customer has granted the required permissions. Within seconds the score is generated and sent to the underwriter. Do note that all CredoApp does is take a 'snapshot' of the device usage and does not track information over time. Once the score has been successfully sent to the backend, the app is defunct and can be deleted.
The Gini coefficient of CredoLab's scorecards varies from client to client. As of today, CredoLab has consistently delivered scorecards with an average of 30% higher Gini coefficient than the traditional scorecards used by the client.
Within a short span of time, CredoLab has grabbed the attention of the right kind of businesses who have partnered with us to offer a wholesome solution to our clients.
Incidents are prioritized based on severity level below to ensure that those with the highest business impact are resolved first. Technical support resources are available during local business hours.
- Level 1: Critical Service Impact (A service failure or severe degradation. Case critically affects the primary business service). 4 business hrs first response time, 24 business hours resolution time.
- Level 2: Significant Service or Implementation Impact (A service failure or severe degradation. Case critically affects the primary business service). 6 business hrs first response time, 72 business hours resolution time.
- Level 3: Moderate Service Impact (Product features are unavailable but a workaround exists). 8 business hrs first response time, 10 business days resolution time.
- Level 4: No Service Impact (Non-critical cases, general questions, enhancement requests, documentation cases, issues that have very little to no impact on functionality). 12 business hrs first response time, 15 business days resolution time.
The file containing the metadata used to calculate the credit score is no bigger than 120kb.
No. The only time the app is active is when the customer initiates the scoring process. Once the score is sent to the backend, the app is defunct. It does not access any data or remain active in the background. The customer is free to delete the app right after the scoring is done.
You can get more information on how we handle the data under our privacy policies.
We have arrived at this 7 step process of developing a scorecard after years of analysis of what goes into designing the perfect engine that can assess the creditworthiness of each applicant efficiently. Each step is executed closely with your team to ensure its customized to your objectives, business, and markets amongst other relevant factors. Here's a snapshot of what the process looks like:
Get in touch with us at partners@credolab.com with your information and our partnership team will get in touch with you right away.
CredoLab agrees, represents, and warrants to use commercially reasonable efforts to resolve errors in a manner consistent with the requirements of the Client, the Agreement, the Services, and our SLA. CredoLab shall use the standard HTTP response codes to indicate specific failure modes. The high-level breakdown of the standard HTTP error conditions and how Client's system will interpret these are as follows:
- 2xx: Supplier API has received, understood, and accepted a request.
- 3xx: Further action is required in order to complete the request.
- 3xx: An error occurred in handling the request. The most common cause of this error is an - invalid parameter.
- 5xx: Supplier API received and accepted the request, but an error occurred while handling it.
Refer to Scoring to know more on how to kick off scoring your customers. Watch the video below to get a quick understanding how the customer would use the app once ready.
Then CredoLab will not be able to generate a score for that applicant. The score is generated based on the information allowed to access. The more permissions granted, the more accurate the score will be reflected and thus, higher the chances of getting a better approval score.
During the scorecard development phase you will be able to monitor the progress of datasets uploaded but will not receive a score. The very purpose of the data collection phase is to collect enough dataset required to tailor-make the scorecard model. After you approve the scorecard, we then put it into production and starts charging a fee per requested score. At the end of the pilot you will receive the scorecard and the underlying features.
CredoLab agrees, represents, and warrants not to post, transmit, retransmit, or store material on or through the CredoLab Infrastructure that:
- is in violation of any applicable local, state, federal, international law, regulation, treaty or tariff; or
- violates the rights of any person, including rights protected by copyright, trade secret, patent or other intellectual property or similar laws or regulations, including, but not limited to, the installation or distribution of pirated or other software products that are not appropriately licensed for use by CredoLab.
CredoLab agrees, represents, and warrants to comply with data protection laws and regulations that apply to the performance of its obligations under this SLA and to process any personal data (including any which forms part of the Client's Data) as a result of, or in connection with, the provision of the Services to the Client strictly in accordance with Clients’s instructions and/or all applicable data protection laws and regulations and not otherwise. CredoLab agrees to take reasonable, appropriate technical, business, and organizational measures against accidental, deliberate, or unauthorized destruction, loss, alteration or disclosure of any data and implement adequate security programs and procedures to ensure that unauthorized persons do not have access to any equipment used to process personal data as part of the Services.
CredoLab agrees, represents, and warrants not to use or disclose Client’s Data or any end-user data, except to perform the Services and conduct activities authorized in this SLA.
We collect data permissions from 8 main, broad categories-- Apps, messages, contacts, image and audio files, emails, calendars and downloads. We allow the customer to control which permissions they want to allow, and which they’d like to decline access to.
Data collection is the process consisting of two steps: Gathering information from customers and Gathering information using the performance data.
In the first step, information is collected from the customers using White-label CredoApp, White-label CredoApply or CredoApp SDK. During this phase you can monitor the datasets uploaded onto CredoLab' servers to check it's quality (no duplicates etc). The data collected is used to train the AI algorithms used to select the most predictive delinquent behavioural patterns.
In order to build a tailor-made scorecard, you also need to provide us with performance data for the disbursed credit alongside the collected metadata from the customers. This performance data file should contain a binary target indicating if a borrower is “good” or “bad” (from credit risk perspective).
Given the behavioural nature of the score, we will tailor-make each scorecard based on the particular population and product that you want to assess.
CredoLab agrees, represents, and warrants that it uses data leakage protection (DLP) mechanisms, network security via TLS, access control policy, system development lifecycle (SDLC), encryption protocols, software baseline configuration system, network security and firewall management, intrusion detection and/or prevention systems (IDS/IPS), environment segregation for relevant systems, and security logging and monitoring policy, among others. These help with the daily monitoring and performance of servers.
The process is completed faster than you can say "CredoLab". The app begins accessing data only after the customer has granted the required permissions. Within seconds the score is generated and sent to the underwriter. Do note that all the app needs to do is take a 'snapshot' of the device usage and does not track information over time. Once the score has been successfully sent to the backend, the app needn’t access any more information for scoring.
You can get more information on how we handle the data under our privacy policies.
In order to build a robust scorecard, we recommend to collect metadata of about 5,000 users of which at least 300 to 500 are defaulters. The total number of uploaded datasets will depend on default rate, approval rate, and penetration of the mobile apps.
CredoLab agrees, represents, and warrants to undertake commercially reasonable measures to ensure that System Availability equals or exceeds the SLC of 95% during each calendar month, excluding Maintenance Windows, provided that any Unscheduled Downtime occurring as a result of the following exclusions: (i) incompatibility of Client’s equipment or software with the CredoLab Infrastructure; (ii) performance of Client's systems or website; or (iii) Force Majeure or (iv) any other circumstances that are not within CredoLab’s control which for purposes of this SLA is limited to scheduled or unscheduled interruptions caused by third party service providers (e.g., third party networks, domain name registrars) and outages on the part of internet service providers, shall not be considered toward any reduction in System Availability measurements or the application of Service Credits provisions. CredoLab shall comply with the following API requirements:
- API Performance: Ability to handle a minimum request rate of 1 request per second (Supplier’s API should be able to serve at least this rate of requests). Ability to handle a maximum request rate of 20 requests per second (Supplier’s API should be able to “burst” to this maximum rate of serving requests). Each API Response should have an average response time < 4000ms (less than 4000 milliseconds).
- API Availability: Supplier APIs shall achieve an uptime of 95% per month.
- Should an emergency dictate a need for any period of non-Availability of CredoLab Infrastructure outside the Maintenance Window, or for a period of non-Availability exceeding 2,160 minutes, CredoLab agrees to schedule such non-Availability at least fourteen (14) calendar days in advance of its commencement with prior concurrence of the Client's representative. Any period of non-Availability outside of the Maintenance Windows shall be treated as “critical” Issue.
Then CredoLab will not be able to generate a score for that applicant. The score is generated based on the information allowed to access. The more permissions granted, the more accurate the score will be reflected and thus, higher the chances of getting a better approval score.
Data Preparation involves processing the raw data so that machine learning algorithms can uncover insights and make predictions. CredoLab uses proprietary software and algorithms to transform the raw data collected during the data collection phase into millions of features which are a foundation of all further steps of a modelling process.
CredoLab agrees, represents, and warrants to use commercially reasonable efforts to determine the source of any excess packet loss or latency and to correct such problem to the extent that the source of the issue is on CredoLab Infrastructure or network.
Yes. Please get in touch with us at info@credolab.com for more information on this.
Segmenting, or clustering, is an unsupervised machine learning algorithm where the target is not known. CredoLab always tests different types of segmentation to make sure the data is homogeneous from a digital footprint point of view. Typically, we use Android version, data availability, device brand and other features to build homogeneous segments in order to increase the overall predictive power of an ensemble of scorecards. This step ensures that demographic information about the individual phone user is NOT included. Variables such as age, sex, income level, etc. are NOT considered for modelling nor extracted from the mobile device for any other purpose.
CredoLab agrees, represents, and warrantsto use standard industry practices to regularly back up all data stored on behalf of the Client in accordance with the Schedule below, and implement a disaster recovery plan in the event of a site catastrophe or other Force Majeure Event that prevents CredoLab from delivering the Services or the client from accessing the Services or CredoLab’s Infrastructure, and agrees to use commercially reasonable efforts to have the Services restored to operation as soon as practicable
Yes. Please get in touch with us at info@credolab.com for more information on this.
Feature selection eliminates irrelevant or redundant features with the aim of increasing accuracy of the scoring model. We typically reduces the number of features from 1,300,000 to about 5,000 via fast and greedy algorithms. We then apply sophisticated proprietary algorithms to accurately select a few dozens of the most predictive and stable features. We always use a few different feature selection algorithms to ensure that we focus on features that are relevant to the problem we are trying to solve (predict risk).
CredoLab agrees, represents, and warrants to back up all Client Data (including but not limited to File Data, Database Data, and Archive Data), on a daily basis using a combination of full and incremental backup procedures. In addition, CredoLab shall archive database logs to permit recovery to a specific point in time if necessary. Backups will be executed automatically using a predefined schedule. Backup records will be rotated offsite on a periodic basis to ensure availability in the event of a site catastrophe. CredoLab agrees to archive and retain such records using predefined schedules and policies.
CredoLab agrees to exercise commercially reasonable efforts to restore data files from archived copies as quickly as reasonably practicable, as necessary as a result of system failure or data corruption or losses. Client acknowledges that the amount of time required to restore data files is dependent upon numerous factors, including, but not limited to, severity or the relevant data corruption or loss. Any expense relative to data restoration is for the account of CredoLab.
No. Our SDK is available in Android native library only (CredoApp SDK). However, SDK module can be integrated into an application written on React Native.
Credit risk models are built to provide a quantitative estimate of the probability that a customer will display a defined behaviour as provided by the bank with their performance data. In our modelling stage, we always divide the available data into a training set, a validation set, and a test set. Consistent with industry practices, the training set is used for fitting the model, the validation set is optionally used to optimize parameters, and the test set is used for reporting the accuracy of the final model with its chosen parameters. Dividing up the dataset in this way for different purposes serves to provide better estimates of actual model performance on individuals who are either new-to-credit or new-to-bank.
Xcode 11.3.
This step is carried out by you along with our assistance.
Model deployment in data science refers to the application of a model for prediction using new data. Depending on your requirements, the model deployment phase can be as simple as generating a report or as complex as implementing a repeatable data science process.
We will provide you with a manual for this step. The manual contains the details of the datasets being used for model building, the subset of features being selected as the most predictive to be included in the final model. The manual also includes the model performance (train vs. test) and the charts summarizing the distribution of the users per risk score.
Swift version 5.2 and higher.
Model calibration is done after a model is deployed in production. Model calibration is the process of fine-tuning and improving the model with new data coming from the same bank. Tuning a model involves changing parameters such as learning rate or optimizer. Or model-specific architecture factors such as number of trees for random forests and number of and type of layers for neural networks.
During the first 12 months, we recommend you share the performance data on a monthly basis. With this data, we can fine tune the model and improve it. As the portfolio matures, we recommend to perform a quarterly or semi-annual calibration.
Part of the calibration process is again out-of-sample and out-of-time validations. These are important steps to avoid overfitting, the practice in which the model fits the empirical data too well which results in less accurate predictive results for the new set of input data.
CredoLab agrees, represents, and warrants to use all commercially reasonable efforts to have the Services running and available to the Client continuously, every day, in dedicated environments of at least 95% during any monthly billing cycle (“Service Level Commitment” or SLC) and a mean time of between any non-Availability equal to or greater than one hundred twenty days (120).
A Scheduled Downtime may be scheduled by CredoLab as reasonably necessary for maintenance, updating, or repair by giving the client at least eight (8) hours advance written notice, unless a shorter notice period is required under the circumstances. The notice will specify the date and start time of the Scheduled Downtime and the expected period during which the Services will non-Available. CredoLab agrees to use commercially reasonable efforts to minimize the effects of such Scheduled Downtime on the Client's regular business operations.
Please refer to the sections below for more on our service level commitment.
Couldn’t find an answer to your query? Get in touch with us directly at faqs@credolab.com.
