How can we help?

Bank statement underwriting reads an applicant's actual deposits and debits, rather than a paystub or a stated figure, to establish income, obligations and repayment behavior. KoraConnect performs it on either a live bank connection or uploaded PDF statements, returning verified income, a true debt load and the risk flags you configured, in about a minute.

A credit score describes how someone paid in the past. Cash flow based lending measures whether they can carry the payment now, from real income and real obligations. That makes it a form of alternative credit underwriting: thin-file, gig-income and credit-invisible applicants become underwritable on evidence instead of being declined for a missing history.

KoraConnect reads an applicant's transaction history, from a permissioned bank connection or from uploaded PDF statements, and finds every recurring income stream in it: what arrives, how regularly, and how long it has run. You decide which streams count toward the figure you underwrite on. The result comes back in about a minute.

KoraScore is Kora’s risk model, trained on real cash flow data and the loan outcomes that followed it. It returns two scores on the familiar 300 to 850 scale, one trained on charge-off and one on reaching 60 or more days past due, both computed from the same file the rest of the analysis reads. It does not return a decision: what a score means for a deal is set by your own credit policy.

A stip, short for stipulation, is a condition a lender requires before funding: proof of income, proof of employment, proof of identity, proof of insurance. KoraConnect collects them through a single link to the customer, and every result for that customer lands on one page rather than arriving separately to be chased.

Yes. KoraConnect resolves every obligation it finds in the bank data, including auto, rent, BNPL, cash-advance apps and payday, into a true monthly debt load and residual income. The proposed payment can then be sized against verified coverage rather than against a stated budget.

Banks, credit unions, auto lenders both direct and indirect, personal loan lenders, SMB lenders, and auto dealers, across the US and Canada. The analysis is the same on every file. What changes by lender is the policy applied to it and the system the result lands in.

The lightest version is no integration at all: your team creates a link on the dashboard and the result appears there in minutes. From there you can embed the connection inside your own application flow, or call the API from your origination system and pull the file back automatically.

If your LOS can make REST calls, yes: four endpoints and a webhook. Teams also run dashboard-only or drop the embeddable widget into an existing flow, and a sandbox is free to build against.

Wherever the application starts. Dealer-originated files arrive with the verification already run through the dealer portal, integrations can be built with DealerTrack or RouteOne, and your own direct applications run the same analysis from your LOS or dashboard. It can be embedded at any point of your underwriting workflow. Same report, same rules, either channel. On an indirect program the dealer sends the customer one link as part of the deal and the analysis comes back with the application, before the contract is signed.

Send 200 or more loans you have already funded, with the statements or transactions you held at underwriting and the outcomes since. Kora returns the model lift, what the analysis would have caught, and the thresholds behind it. There is no cost and nothing to sign.

No. Kora returns verified income, the obligations behind it, the risk signals it found and a KoraScore, and your credit policy decides what weight any of it carries. Lenders typically start by running it beside their existing decision on a single product.

A live bank connection, uploaded PDF bank statements, or raw transaction data you already hold from a connector. Every path lands in the same pipeline and produces the same report.

Up to twelve months of transaction history where the institution provides it. Twelve months is the full window, and every figure is recomputed for the last three and six months as well, so a trend never hides inside an average. Shorter histories still return a figure, and a file covering less than a month is flagged as such rather than averaged as though it were complete.

It carries the same analysis. A connection arrives already structured, so there is nothing to extract and nothing to forge, which is why it is offered first. An uploaded PDF is read line by line, the arithmetic is reconciled from the opening balance to the closing balance, and the file is scanned for tampering before any number is trusted. Both paths produce the same labels and the same categories, and a reconciled statement sits well ahead of a manual statement review.

They can upload statements or paystubs instead, and the documents are extracted with the arithmetic reconciled and checked for editing rather than trusted. You can also send raw transaction data from the aggregator you already use. Between a connection and statements, the coverage is every applicant.

No. They connect whichever accounts their money actually moves through, at your institution or anywhere else, and every connected account is read the same way. Someone who keeps their pay at another institution is still readable.

It is still scored, and the response says plainly that it was scored on limited business evidence rather than presenting the read as complete. Because classification runs on transaction behaviour, a personal account carrying payroll runs, card settlements and commercial rent is analysed as a business anyway. Where there is genuinely no business-side activity the file comes back as a thin one for these purposes, which is usually the point to ask for a business statement.

The status will be refreshed from the carrier record rather than read off the printed declarations page, so a cancellation since the page was issued shows up as cancelled, with the refresh date on the report.

One decision-ready report: verified income by stream, typed obligations with a pre-loan debt-to-income, the risk indicators with their severity and the conditions that tripped them, a KoraScore with its top drivers and reason codes, and the identity and document checks. It arrives in the dashboard, over the API, or as a PDF.

The verified income with each stream behind it, the obligations leaving the account typed by what they are, the affordable payment at your own ratio, a KoraScore, and any signal that crossed one of your thresholds along with the exact condition it crossed. The labeled transaction ledger sits underneath all of it.

One is trained on charge-off and one on reaching 60 or more days past due. Both return a score on the familiar 300 to 850 scale for the applicant in front of you. Neither returns a decision, a recommendation, or a queue order: what a score means for a deal is set by your own policy.

The labeling and the derivation run inside the analysis itself rather than in an overnight batch or a human review queue, so the figure is available while the deal is still live.

Under 45 seconds end to end, and 90% of analyses finish inside 10 seconds. That is short enough to answer someone still in the session rather than emailing them a decision the next day.

Every response carries a completeness tier, and confidence is set by the weakest part of the analysis rather than averaged, so one strong component cannot mask a weak one. A blank section and a poor number are also different things: no business activity found reads differently from a business that was analysed and is struggling, and the score treats them as the different risks they are.

The policy read out: carrier, policy number, effective dates, premium, each coverage line with its limit or deductible, the insured party and the vehicle checked against the deal, the lienholder line, and the refresh date the status was current as of.

A REST API with signed webhooks, a dashboard carrying the full labeled transaction ledger, and a PDF for the file. Most lenders consume the verified income, the obligations, the risk indicators and the score straight into a scorecard they already run.

Nothing about the process changes, and these are the files it was built for. A bureau needs a repayment record to say anything at all; cash flow needs a bank account. The analysis reads which deposits recur and how steady they are, what leaves the account every month and what kind of obligation each payment is. An applicant with twelve months of banking and no tradelines produces a full file, with the same income streams, obligations, residual and score as a thick one. Most lenders run it alongside a bureau pull, and for no-hits it becomes the primary signal.

Every inflow is classified into one of three tiers. Card processor settlements, customer ACH, client wires, marketplace payouts and cash deposits are operating revenue and count. Asset sales, insurance proceeds and refunds are tracked but excluded. Loan disbursements, owner equity injections, internal transfers and tax refunds are never counted as revenue, because counting them inflates the very ratio you are underwriting on.

Yes, and it is the signal the default rule set treats most severely. Advance repayments are recognized by their daily and weekly debit pattern and by provider, so concurrent advances from multiple providers surface as stacking. Advance payments are also placed above everything else in the expense waterfall, since that is their real seniority against the account.

It reports zero rather than disappearing, which matters: an absent signal and an unmeasured one are different facts, and a rule that depends on a check being enabled says so in its own condition.

The disagreeing field is named, with what the application said next to what the document says, and the file routes to review. The other modules keep running and the stage advances, so one doubtful field never stalls the deal.

The difference is reported as a figure with a level of high, low or none, and the specific transactions that do not resolve come back with it, per account and per period. A reviewer looks at the lines rather than accepting a verdict.

The report names the fix, add the lender as loss payee, so the stip becomes a to-do the dealer can act on the same day rather than a bare failure.

Entirely. The payment-to-income cap, the income basis, which obligations count, every threshold and which risk indicators are switched on are configured per lender and then applied identically to every file. A default rule set ships with the model if you would rather start from ours and adjust. Kora computes the condition and reports what tripped it; where the line sits is yours.

Every score ships with its top drivers in plain English, each with a reason code, and every risk flag on the same file carries the exact condition and the value that crossed it. A reviewer reads the rule rather than taking a level on faith, and your compliance team sees the why on file rather than a black box.

Each flag ships with a default condition and level, and those are replaced with yours, set per program so a near-prime book and a subprime book do not share a cutoff. They are revisited on the same quarterly cadence as the score, or whenever your risk appetite moves.

No. Kora verifies, scores, and reports the conditions your configuration asked it to check, and delivers that to your team. Whether a file is approved, conditioned or declined is your decision, made on your policy, in your system.

Bank statements are the live path, and the document checks run on whatever was uploaded for the analysis. The detection reports which document types it recognized in the file, so a submission that is not what it claims to be is visible as well.

Yes, and image provenance is part of what the check reads: whether an embedded image carries the characteristics of a genuine capture device, or has been re-encoded somewhere along the way.

The finding is recorded with the exact condition that produced it and the indicator behind it, and it sits at the top of the report rather than somewhere inside it. What that means for the deal is set by your own rules, not by us.

Yes. Trust indicators are returned alongside risk ones, with their own ids and descriptions, so a file that passes carries the evidence for why rather than an absence of findings.

They open one secure link and complete whatever the deal still needs on it: connecting a bank or uploading statements, photographing the front and back of an ID and taking a short selfie, connecting an insurance account or uploading a declarations page. The application’s own details are carried in behind the scenes, so nothing is typed and nothing is asked twice. There is nothing to install, and each step takes about a minute.

As many as your program needs. A stage carries the steps you want at that point in the deal, each marked required or optional, and a step that appears in more than one stage is the same step carrying its status forward rather than a second copy.

Whatever they completed stays completed, and the same link opens on what is still outstanding. Nothing has to be reissued, and nothing already provided is requested again.

Yes, against whatever has been provided since. Re-run it with additional bank statements, re-invite the applicant, or refresh a connected account and a new analysis runs on current data, which is useful for aged applications and funding-day checks. Runs are recorded individually rather than overwriting one another, each with a snapshot of the setup that produced it, so the file shows what was known at the time a decision was made. A capture that produced nothing usable can be retaken by the applicant up to two times, and your team can reset a finished file up to three.

Workflows are versioned, so a change applies going forward rather than retroactively. Moving a live deal onto a different workflow keeps everything already collected and only adds what the new one asks for.

They create the application and see the status of the steps on that deal. The results, the analysis behind them, and the configuration all sit with you.

Government-issued photo IDs, photographed by camera in the applicant flow. Early access starts with US driver’s licenses, and further government ID types follow.

The applicant permissions it, every time, either by connecting a bank or by uploading statements. Kora collects nothing from data furnishers and runs a fresh analysis for each request, and no second lender is given access to the file your applicant shared with you.

Access is role-based (RBAC): a teammate sees them only if their role allows it, and every view passes that check. They are never downloadable, and they are encrypted at rest in storage Kora controls. The SSN, when the application carries one, is encrypted at rest as well, used only for the record check, and never shown back.

SOC 2 Type II, ISO/IEC 27001, and GLBA Safeguards. Your security team can request the reports through the contact form below.