Latency Budgets for Lending: Borrowing an Engineering Discipline

Ask a site reliability engineer how long a service is allowed to take and you get a number with a percentile attached. Ask a lender how long income verification is allowed to take and you get a story about the applicant, the bank, the underwriter and the time of year. Both answers are true. Only one of them is enforceable.

The gap is not analytical sophistication. Lenders measure plenty. The gap is that engineering assigns its time allowance before the work happens, in writing, per step, and treats an overrun as an event rather than as weather.

A latency budget in lending is a written time allowance given to each step of an intake flow, with the total capped at a target the whole flow has to meet. The method comes from engineering. Set the end-to-end target first, divide it across the steps, measure at a percentile, and treat every overrun as a decision.

What is a latency budget?

A latency budget is a per-step time allowance, agreed in advance, whose sum equals the maximum acceptable time for the full path. In software it is counted in milliseconds across services. In lending intake it would be counted in minutes across steps: identity capture, consent, bank connection, income read, employment evidence, submission.

Two things separate a latency budget from a service level agreement. It is internal, so nobody is paying penalties. And it is decomposed, so an overrun has an address. "Applications take too long" is a complaint that dies in a meeting. "The employment step is budgeted at three minutes and is running at seven at the 75th percentile" is a work item with an owner.

How do engineers actually set these numbers?

Google's Site Reliability Engineering book defines a service level objective as "a target value or range of values for a service level that is measured by an SLI," and its worked example for a low-level storage service is tiered by percentile: "90% of Get RPC calls will complete in less than 1 ms," rising to "99.9% of Get RPC calls will complete in less than 100 ms."

Two pieces of guidance travel further than the numbers. The first, from the service level objectives chapter, is "Don't pick a target based on current performance," because a target reverse-engineered from today's behaviour commits a team to defending whatever it already does. The second, from the chapter on embracing risk: "100% is probably never the right reliability target: not only is it impossible to achieve, it's typically more reliability than a service's users want or notice." The distance between target and measured reality becomes the error budget, and in Google's framing, as long as error budget remains, new releases can be pushed.

Google's Core Web Vitals apply the same shape to the public web: 2.5 seconds for Largest Contentful Paint, 200 milliseconds for Interaction to Next Paint, 0.1 for Cumulative Layout Shift, and web.dev is explicit that the measurement point is "the 75th percentile of page loads, segmented across mobile and desktop devices." Not the average. The 75th percentile, because an average conceals the quarter of users having the worst experience, and those are the ones who leave.

The oldest version of this discipline predates most lending software. Jakob Nielsen's response time limits, published in 1993 and still hosted by Nielsen Norman Group, give three: 0.1 second is "the limit for having the user feel that the system is reacting instantaneously," 1 second is "the limit for the user's flow of thought to stay uninterrupted, even though the user will notice the delay," and 10 seconds is "the limit for keeping the user's attention focused on the dialogue."

Banking infrastructure already reports against such numbers. Open Banking Limited's API performance statistics for June 2026 record an average response time of 349 milliseconds across the nine account providers and twenty brands in scope, with 99.80% weighted availability and 99.50% of roughly 2.8 billion API calls succeeding. Those figures are published monthly, per brand. The banks on the other end of a bank connection step already live inside a latency standard.

Where does the analogy stop?

The move from milliseconds to minutes is an analogy. The engineering research above establishes nothing about lending intake. Nielsen's 10 second limit describes attention during a single interface response, not whether a borrower abandons a twenty minute document collection at minute nine or minute fourteen. Core Web Vitals thresholds came out of page load research on the consumer web, not application completion research on credit files. The Get RPC targets in the SRE book describe a storage system that has no opinion about being asked for a pay stub twice.

What transfers is the method. Set the total before dividing it. Decompose the path so overruns have owners. Measure at a percentile. Hold a reserve. None of that depends on the unit being a millisecond.

What does not transfer is any specific number. A lender importing 2.5 seconds or 349 milliseconds into an intake conversation is importing somebody else's problem.

What does a lending latency budget look like on paper?

The figures in this table are illustrative. They show the shape of a budget for a consumer lending flow, and are not drawn from any study, benchmark, survey or measured lender flow.

Step	Budget at p75	Clock starts	Clock stops	Common overrun cause
Identity capture	1.5 min	First field focused	Identity submitted	Manual address entry
Consent and disclosure	0.5 min	Consent screen shown	Consent recorded	Long legal text, no summary
Bank connection	2.0 min	Institution picker opened	Connection confirmed	Credential retry, MFA relay
Income and affordability read	1.0 min	Connection confirmed	Income figures returned	Data pull depth, provider latency
Employment evidence	3.0 min	Income returned	Evidence accepted	Fallback to document upload
Application remainder	3.0 min	Evidence accepted	Submit pressed	Fields already known internally
Submit to decidable file	1.0 min	Submit pressed	File marked decidable	Sync jobs, queue handoff
Reserve (unallocated)	2.0 min	n/a	n/a	Absorbs one bad step per file
Total	14.0 min

Table 1: an illustrative latency budget for a consumer lending intake flow, measured at the 75th percentile. The figures are constructed to demonstrate the method and are not benchmarks. The reserve row is the lending equivalent of an error budget: time deliberately left unassigned so that one slow step does not automatically breach the whole flow.

The reserve row is the part most teams remove first, and removing it is the mistake. A budget with no slack fails on its first bad Tuesday, and a budget that fails every Tuesday stops being consulted by Thursday.

How do you build one for your own flow?

1. Set the end-to-end target first, from a commercial constraint rather than from current performance, per the SRE book's advice against reverse-engineering a target.
2. Draw the path as steps a stopwatch could separate. If two share a boundary, treat them as one until instrumentation improves.
3. Instrument the boundaries, not the page. Every step needs a start event and a stop event with real timestamps, per application.
4. Measure four weeks of baseline at the median and the 75th percentile, split by channel and product. Aggregates hide the segment that is stalling.
5. Divide the target across steps deliberately, and not in proportion to today's timings. A step that currently takes eight minutes because it is doing something avoidable gets a budget of two, and the gap becomes the roadmap.
6. Hold back ten to fifteen percent as unallocated reserve. This is the error budget analogue, and it keeps the budget usable when an aggregator has a slow morning.
7. Publish it where product, operations and credit can all see the same numbers. A budget one team owns privately is a dashboard.
8. Review monthly. One step, one owner, one number, one decision.

Step four is where this usually stalls. Most intake stacks record when an application was created and submitted and nothing between, so month one is instrumentation, not optimization.

What happens when a step goes over budget?

The web.dev guidance on performance budgets, written by Milica Mihajlija and last updated in November 2018, gives three responses when a metric exceeds its limit: "Optimize an existing feature or asset," "Remove an existing feature or asset," or "Not add the new feature or asset."

Translate that into intake and the third option is the whole discipline. Optimize the step, remove the step, or decline to add the new field, document request or check that would push the flow past its total. The first two are easy. The third requires telling a colleague with a legitimate reason that their addition costs ninety seconds the flow does not have, and that is exactly where lending latency budgets tend to die.

In the private credit years the step that blew the schedule was almost never the underwriting. It was the second request for a document the borrower had already sent, going out on a Thursday afternoon and coming back Monday morning. Nothing in those four days was work. It was queue, and a queue is invisible to any measurement system that only records created-at and submitted-at.

What we don't know

No standards body publishes latency targets for lending intake. There is no lending equivalent of Core Web Vitals, no regulator-set per-step allowance, and no convention on where step boundaries even fall. Every budget of this kind is a house convention.

There is also no published elasticity of application completion to elapsed minutes in lending. That figure would tell a lender how tightly to set the total, and it does not appear in public literature. It has to be measured inside a specific flow.

And nothing says the 75th percentile is the right measurement point for a borrower. Google chose it for page loads, with page load data behind that choice. Applying it to a lending flow is a borrowed convention, defensible mainly because averages are worse.

Common questions

What is a latency budget in lending?
A latency budget in lending is a written per-step time allowance across an intake flow, with the sum capped at a target for the whole flow. Each step carries a number measured at a percentile, usually the 75th, and any step over its allowance triggers a decision rather than a note.

How is a latency budget different from an SLA?
A service level agreement is external and carries penalties for breach. A latency budget is internal, decomposed step by step, and exists to force trade-off decisions during design rather than compensation after failure. Google's Site Reliability Engineering book draws the same distinction between agreements, objectives and the indicators underneath them.

Why measure at the 75th percentile rather than the average?
Averages hide the worst quartile of experiences, the group most likely to abandon. Google's Core Web Vitals guidance sets its thresholds at "the 75th percentile of page loads, segmented across mobile and desktop devices" for that reason. The convention carries into intake flows even though the research behind it does not.

Does engineering research prove faster intake converts better?
No. The response time limits published by Jakob Nielsen in 1993 and the Core Web Vitals thresholds describe interface responsiveness on the consumer web, not loan application completion. The transfer from milliseconds to minutes is an analogy about method. Any claim about conversion needs measurement inside the lender's own flow.

What is a realistic total for an intake latency budget?
There is no published figure, and any number quoted as an industry standard is unsourced. The defensible approach is to derive the total from a commercial constraint, divide it across steps, and hold a reserve of ten to fifteen percent, following the error budget logic in Google's Site Reliability Engineering book.

---

Carousel's intake flows are instrumented step by step, so a latency budget has real numbers to sit on. See how verification fits your flow