What an API is and why lenders depend on them

An agreed way for systems to talk

The Basel Committee on Banking Supervision, in its 2019 report on open banking and APIs, defines an API as a set of rules and specifications for software programs to communicate with each other. In practice one system sends a request in an agreed format, such as a customer's identity number and the purpose of the enquiry, and the other system sends back a response in an agreed format, such as a credit report or an error message. Neither side needs to know how the other is built inside; both only need to follow the agreement.

That separation is what lets a lender change one part without rebuilding the others. If the ledger is replaced, the decision engine can keep working as long as the new ledger answers the same requests in the same way.

Where a lender uses APIs

The course on how a digital lending platform is built followed a loan through its parts. Almost every step between those parts, and between the lender and the outside world, is an API call. A working list for one loan:

• Identity: checking the applicant's identity document against an identity service.
• Credit data: asking a credit bureau for the applicant's report.
• Shared data: receiving bank-account data that the applicant has agreed to share.
• Decision: passing the application from the onboarding system to the decision engine and back.
• Money: instructing the disbursement and receiving notice of each repayment.
• Partners: receiving applications from a partner's app where the loan is offered inside another service.

What APIs replaced

Before APIs, third parties often collected bank data by screen scraping. The Basel report describes screen scraping as using automated scripts to collect displayed data elements from one application, and notes that screen scraping requires the customer to give the third party his or her bank login credentials. It calls such techniques unsecure for the customer. The report notes that banks are finding that APIs provide more control over the type and extent of data shared and are a more secure way to interact with third parties.

Open banking: data the customer permits

APIs also let a customer's data leave the bank that holds it. The Basel report defines open banking as the sharing and leveraging of customer-permissioned data by banks with third party developers and firms. It found three broad approaches among jurisdictions: prescriptive, requiring banks to share customer-permissioned data, with Thailand among the examples; facilitative, issuing guidance and recommended standards, with Singapore among the examples; and market-driven, with no explicit rules or guidance, with the United States among the examples. A 2026 BIS paper reports that by 2024, 95 jurisdictions had some form of an open banking or open finance policy framework in place.

For lenders the interest is in credit. The same BIS paper, citing research on the United Kingdom, reports that open banking allowed small and medium-sized enterprises to form new credit relationships with non-bank lenders. Lesson 2 of this course looks at how such data sharing works and what the customer's consent has to cover.

How long a decision waits

Every outside call adds waiting time to a decision, and how the calls are arranged decides how much. Calls that depend on each other must run one after another; calls that do not can run at the same time.

Waiting time for calls made one after another = the sum of their response times. Waiting time for calls made at the same time = the longest of their response times.

Example, with illustrative numbers: an identity check answers in 2 seconds, a credit bureau in 3 seconds and a bank-data service in 5 seconds. Made one after another, the three calls take 10 seconds. If the bureau and bank-data calls can run at the same time once identity is confirmed, the wait is 2 seconds plus the longer of 3 and 5, that is 7 seconds. The design choice is not only about speed: running the bureau enquiry before identity is confirmed would send a person's data to a bureau for someone who may not be who they claim to be.

Every connection is also a risk

The Basel report is clear that connections bring risks as well as benefits. It finds that data sharing results in a bigger surface area for cyber attacks; that oversight of third parties can be limited, especially where banks have no contractual relationship with them; that it is not always clear which party, the bank, a third party or a fourth party, is liable when a transaction is fraudulent or wrong; and that banks may face reputational risk even where liability rules are established. It also notes that there is no globally adopted API standard.

Lesson 6 of the course on how a digital lending platform is built showed that a lender stays responsible for every part a third party runs. An API connection is often where that responsibility is tested first. Lesson 4 of this course covers how connections are kept safe, and lesson 5 how they are run.