How to test a lending platform
Direct answer
Shipped untested, a lending platform pulls autopay repayments from a bank account the borrower never authorized or on a date covered by a granted extension, and originates and disburses loans in stolen identities because the application flow misses altered pay stubs and mismatched IDs. 9 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with unit tests on APR, amortization and late fees: every schedule, autopay debit and credit bureau status downstream is built from these calculations.
9 mandatory testsfirst: unit tests
What counts as a lending platform
A lending platform here is a web and mobile product that originates, scores and services loans to consumers or businesses: application, identity and income checks, automated credit decisions, loan agreements, repayment schedules, autopay and furnishing to credit bureaus. Instalment plans offered at a merchant checkout, credit cards and mortgage servicing by a separate servicer are out of scope.
Adjacent product types not covered here
- buy now pay later service: A buy now pay later service approves short instalment plans inside a merchant checkout, so merchant refunds and plugin contracts replace adverse action notices and credit bureau files.
- mobile banking app: A mobile banking app holds deposits rather than lending them, so overdraft fees on settled card purchases and payee scams replace underwriting and autopay authorisation.
- insurance app: An insurance app prices policies from filed rates, so rating data loads and claims model drift replace loan schedules and bureau reporting.
Risk map
| Risk | Grade | Note | Evidence | |
|---|---|---|---|---|
| Fraud or abuse by users fraud-abuse | money | primary | A loan is originated and disbursed in a stolen identity because the application flow does not flag altered pay stubs or a mismatched ID. | |
| Money leaves or fails to arrive money-loss | money | primary | Autopay pulls a repayment from a bank account the borrower never authorized, or still debits on a date the borrower was granted an extension. | |
| Fine or enforcement by a regulator regulatory-penalty | legal | primary | A credit denial goes out without specific principal reasons, or furnished tradelines report borrowers as delinquent in error, and the lender faces ECOA or FCRA enforcement. | |
| Personal or sensitive data exposed data-breach | data | secondary by design analysis | By design analysis: a loan file holds pay stubs, bank statements, SSN and a credit report, and an ID change in the loan URL can expose another applicant's file. | |
| Records silently wrong data-corruption | data | practitioner single incident, no second source | The credit bureau file reports an on-time borrower as delinquent because servicing status and furnished status drift apart. | |
| Users or operators act on wrong numbers wrong-decisions | trust | primary | The underwriting model declines an applicant for one reason while the adverse action notice lists different reasons drawn from a static template. |
Mandatory tests (9)
Step 1: release smoke tests
Why:money-loss
Done when: After each release, a test borrower can apply, sign the loan agreement and see the first repayment scheduled against the account they named.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 2: unit tests
Done when: APR, amortization schedule and late-fee results match a reviewed spreadsheet for every loan product, including month-end and leap-day due dates.
Tool class: unit framework. Who usually runs it: developer.
Step 3: integration tests
Done when: A repayment posted by the processor updates the loan balance and next due date on the servicing screen, and a returned payment reverses both.
Tool class: API client. Who usually runs it: QA engineer.
Step 4: penetration testing
Done when: An external tester cannot open another borrower's loan file by changing an ID, and cannot submit an application that skips the identity check.
Tool class: proxy. Who usually runs it: external lab.
Step 5: compliance checks
Why:regulatory-penaltyfraud-abuse
Done when: For a sample of applications, a reviewer finds the dated disclosures, the identity checks performed and the adverse action notice stored with each file.
Tool class: test management. Who usually runs it: product manager.
Step 6: payment and money-flow testing
Why:money-loss
Done when: In the payment sandbox, an autopay debit pulls only from the account the borrower authorized, and a granted extension cancels the debit scheduled for that date.
Tool class: API client. Who usually runs it: QA engineer.
Step 7: end-to-end functional tests
Why:wrong-decisionsregulatory-penalty
Done when: A declined test application produces an adverse action notice whose reasons match the factors the decision engine logged for that applicant.
Tool class: browser automation. Who usually runs it: QA engineer.
Step 8: data integrity and migration testing
Why:data-corruptionregulatory-penalty
Done when: The credit bureau file for a set of test loans shows the same status, balance and days past due as the servicing screen, including a loan paid on its due date.
Tool class: data validation. Who usually runs it: QA engineer.
Step 9: security scanning
Why:data-breach
Done when: The latest scan of the application portal and loan API shows no open finding that exposes bank statements, SSNs or credit reports.
Tool class: DAST scanner. Who usually runs it: security specialist.
Recommended and optional tests
regression suiterecommended
Becomes mandatory when more than one loan product shares the servicing engine.
resilience and failure testingrecommended
Becomes mandatory when debits are retried automatically after a failure.
contract testsrecommended
Becomes mandatory when underwriting reads more than one external data provider.
accessibility testingrecommended
Becomes mandatory when an accessibility complaint or a public-sector lending program applies.
exploratory testingoptional
Session-based exploration of payoff quotes, partial payments and early settlement may find schedule edge cases the unit cases miss.
device and browser compatibilityoptional
Document upload of pay stubs from older phones may fail on camera or file-type handling.
Not needed and why
Not needed for risk control: no attached risk depends on comprehension testing. Becomes recommended when application drop-off is a tracked product goal.
Not needed: loan applications arrive steadily and no peak-load incident is recorded for this type. Becomes recommended when a marketing campaign or rate promotion drives application spikes.
Not needed: disclosures are issued in one language and one jurisdiction. Becomes recommended when the platform lends in a second language or country.
Order of work
First release
- release smoke tests: As a test borrower, apply, sign the loan agreement and confirm the first repayment is scheduled against the account the borrower named.
- unit tests: Run APR, amortization schedule and late-fee calculations for every loan product against the reviewed spreadsheet, including month-end and leap-day due dates.
- integration tests: Post a repayment from the processor and confirm the loan balance and next due date update on the servicing screen, then return the payment and confirm both reverse.
- penetration testing: Have an external tester change the loan ID to open another borrower's file and try to submit an application that skips the identity check.
- compliance checks: Pull a sample of applications and confirm each file stores the dated disclosures, the identity checks performed and the adverse action notice.
- payment and money-flow testing: In the payment sandbox, run an autopay debit and confirm it pulls only from the authorized account, then grant an extension and confirm the debit for that date is cancelled.
- end-to-end functional tests: Submit a test application the decision engine declines and compare the adverse action notice reasons with the factors logged for that applicant.
- data integrity and migration testing: Generate the credit bureau file for a set of test loans and compare status, balance and days past due with the servicing screen, including a loan paid on its due date.
- security scanning: Scan the application portal and loan API and close every finding that exposes bank statements, SSNs or credit reports.
Ongoing cadence
- release smoke tests: After every release of the application or servicing flow.
- unit tests: After each change to rates, fees or schedule rules for any loan product.
- end-to-end functional tests: After each change to the decision engine or the adverse action notice template.
- data integrity and migration testing: Before each credit bureau file is sent.
- payment and money-flow testing: After each change to autopay, extensions or the payment processor.
- contract tests: When a credit bureau or bank-data provider changes its response format.
- regression suite: On every release candidate once more than one loan product shares the servicing engine.
Tools
Listed alphabetically inside each test type, filtered to the tests above and to the platforms of lending platform (web, ios, android). Not recommendations.
release smoke tests
- Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
unit tests
integration tests
- Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
- JestJavaScript test runner with mocking and snapshots. webapiopen-source
- JUnitTest framework for the JVM. apiandroidopen-source
- VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
penetration testing
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
payment and money-flow testing
- Adyen test environmentTest cards and scenarios for Adyen integrations. webapiiosandroidcommercial
- Stripe test modeTest cards and scenarios for Stripe integrations. webapiiosandroidfreemium
end-to-end functional tests
- AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
- ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
- BrowserStackCloud of real devices and browsers. webiosandroidcommercial
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
- EspressoAndroid UI testing framework from Google. androidopen-source
- LambdaTestCloud browser and device grid. webiosandroidcommercial
- MaestroMobile UI flows written in YAML. iosandroidfreemium
- PercyVisual review of UI changes. webcommercial
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
- SeleniumWebDriver-based browser automation. webopen-source
- XCTestApple's framework for unit and UI tests. iosopen-source
security scanning
- Burp SuiteProxy and scanner for web application security testing. webapifreemium
- mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
- MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
- OWASP ZAPDynamic application security scanner. webapiopen-source
- SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
- SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium
regression suite
- CypressBrowser-based end-to-end testing with a visual runner. webfreemium
- PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
- PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
- TestRailTest case and run management. webiosandroidapicommercial
- XrayTest management inside Jira. webiosandroidapicommercial
accessibility testing
- Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
- axe-coreAccessibility rules engine for automated checks. webopen-source
- LighthouseAudits for accessibility and performance in Chrome. webopen-source
- Pa11yCommand-line accessibility testing. webopen-source
What to send to the person who will test
Send the checklist and the brief below. The printable checklist for lending platform has the same 9 items with checkboxes.
Download the checklistMarkdownCSVBrief (Markdown)
Acceptance criteria wording
A release of the lending platform is accepted when a test borrower can apply, sign and see the first repayment scheduled against the named account, and autopay in the sandbox pulls only from that account and skips a date covered by an extension. A declined test application produces an adverse action notice whose reasons match the logged decision factors. The credit bureau file for the test loans shows the same status, balance and days past due as the servicing screen.
Brief
# Test brief: lending platform Product type: lending platform. A product that originates, scores and services loans to consumers or businesses. Risk map and evidence: https://howtotestaproduct.com/how-to-test/lending-platform/ Printable checklist: https://howtotestaproduct.com/checklists/lending-platform/ Run these 9 mandatory tests in this order. A test is done only when its done condition is true on the build you will release. 1. release smoke tests (risks: money-loss). Tool class: browser automation. Usually run by: QA engineer. Done when: After each release, a test borrower can apply, sign the loan agreement and see the first repayment scheduled against the account they named. 2. unit tests (risks: data-corruption, money-loss). Tool class: unit framework. Usually run by: developer. Done when: APR, amortization schedule and late-fee results match a reviewed spreadsheet for every loan product, including month-end and leap-day due dates. 3. integration tests (risks: money-loss, data-corruption). Tool class: API client. Usually run by: QA engineer. Done when: A repayment posted by the processor updates the loan balance and next due date on the servicing screen, and a returned payment reverses both. 4. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: external lab. Done when: An external tester cannot open another borrower's loan file by changing an ID, and cannot submit an application that skips the identity check. 5. compliance checks (risks: regulatory-penalty, fraud-abuse). Tool class: test management. Usually run by: product manager. Done when: For a sample of applications, a reviewer finds the dated disclosures, the identity checks performed and the adverse action notice stored with each file. 6. payment and money-flow testing (risks: money-loss). Tool class: API client. Usually run by: QA engineer. Done when: In the payment sandbox, an autopay debit pulls only from the account the borrower authorized, and a granted extension cancels the debit scheduled for that date. 7. end-to-end functional tests (risks: wrong-decisions, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer. Done when: A declined test application produces an adverse action notice whose reasons match the factors the decision engine logged for that applicant. 8. data integrity and migration testing (risks: data-corruption, regulatory-penalty). Tool class: data validation. Usually run by: QA engineer. Done when: The credit bureau file for a set of test loans shows the same status, balance and days past due as the servicing screen, including a loan paid on its due date. 9. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist. Done when: The latest scan of the application portal and loan API shows no open finding that exposes bank statements, SSNs or credit reports. Acceptance criteria wording: A release of the lending platform is accepted when a test borrower can apply, sign and see the first repayment scheduled against the named account, and autopay in the sandbox pulls only from that account and skips a date covered by an extension. A declined test application produces an adverse action notice whose reasons match the logged decision factors. The credit bureau file for the test loans shows the same status, balance and days past due as the servicing screen. Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file). Licence: CC BY 4.0.
For founders: what to forward and what to ask back. For product managers: turning this page into tickets.
Questions about testing a lending platform
What testing does a lending platform need?
9 tests are mandatory, from the apply-and-sign smoke test and unit tests on APR and schedules to credit bureau file reconciliation and security scanning of the loan API. Each is tied to one of the 6 risks in the map, such as an on-time borrower reported as delinquent or an autopay debit from an unauthorized account. Regression, resilience, contract and accessibility tests are recommended, each with the event that makes it mandatory.
What testing is required for a lending platform as a financial product?
End-to-end tests of declined applications, compliance checks on stored disclosures and identity checks, and credit bureau file reconciliation are mandatory while the platform lends to consumers in a regulated market. The map cites the CFPB circular on specific denial reasons under ECOA, and FCRA enforcement for inaccurate credit reporting.
Which tests in a vendor test plan for a lending platform are not needed?
Performance testing is not needed while applications arrive steadily, until a rate promotion drives application spikes. Localization is not needed while disclosures are issued in one language and one jurisdiction. Usability testing is not needed for risk control while no attached risk depends on how applicants understand the form, until application drop-off is a tracked product goal.
When is test automation worth it for a lending platform?
Unit tests are mandatory while the platform calculates its own schedules and fees, checking APR, amortization and late fees for every loan product. The regression suite becomes mandatory when more than one loan product shares the servicing engine, rerunning repayment, extension and payoff cases from past defects on every release candidate.
Evidence
ev-0102regulatorprimary
Fighting Identity Theft with the Red Flags Rule: A How-To Guide for Business, Federal Trade Commission
Supports fraud-abuse for a lending platform: creditors with covered accounts must detect identity theft signals such as altered documents at application, which is where loans are taken out in another person's name. BNPL providers extend consumer credit and are creditors in the same sense.
published undated · verified 2026-10-07
ev-0026regulatorprimary
Electronic Fund Transfers (Regulation E), Consumer Financial Protection Bureau
Regulation E sets error resolution and liability rules for consumer electronic fund transfers, so wrong or unauthorised transfers must be investigated and corrected.
published undated · verified 2026-10-07
ev-0098court-or-fineprimary
Enova International, Inc. (2023 enforcement action), Consumer Financial Protection Bureau
The Bureau found that Enova violated the 2019 Order and the CFPA, including by debiting or attempting to debit consumers' accounts without their authorization.
Supports money-loss for a lending platform: an online lender debited borrower bank accounts the borrowers had not authorized and failed to honor loan extensions it had granted, so repayment debits must follow the stored authorization and extension state.
published 2023-11-15 · verified 2026-10-07
ev-0099court-or-fineprimary
CFPB Orders Hyundai to Pay [amount] for Widespread Credit Reporting Failures, Consumer Financial Protection Bureau
Supports data-corruption for a lending platform: a loan servicer's systems furnished inaccurate account information to credit reporting companies and borrowers were reported delinquent through no fault of their own.
published 2022-07-26 · verified 2026-10-07
ev-0100regulatorprimary
CFPB Acts to Protect the Public from Black-Box Credit Models Using Complex Algorithms, Consumer Financial Protection Bureau
Supports wrong-decisions and regulatory-penalty for a lending platform: creditors using algorithmic credit decisions must still give declined applicants the specific, accurate reasons, so the decision engine and the notice must agree.
published 2022-05-26 · verified 2026-10-07
ev-0012standardprimary
OWASP API Security Top 10 2023, OWASP Foundation
The API Security Top 10 names API-specific failures such as broken object level authorization and unrestricted resource consumption.
published undated · verified 2026-10-07
ev-0101regulatorprimary
FTC Safeguards Rule: What Your Business Needs to Know, Federal Trade Commission
General requirement for data-breach on a lending platform: the rule names lenders and finance companies as covered financial institutions and requires penetration testing and periodic vulnerability scans. A BNPL provider extends consumer credit as a finance company, so the same requirement transfers to it.
published undated · verified 2026-10-07
Disclaimer
This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.