Consumer lending end to end, from application to collections.

Someone starts an application on a phone in the evening, gets interrupted, and comes back to it the next day. The save-and-resume link brings that borrower back without retyping anything, and camera capture is how a pay stub or a void cheque arrives at all. Two-step pre-qualification matters on a small-dollar book because every declined full application generates an adverse-action notice: the criteria that screen for province, income and product run first, on a form you can embed on your own site behind a whitelisted domain. The form designer carries a separate field set per product, so a payday application asks for a pay cycle while an instalment application asks for a term. Repeat borrowers are the bulk of a consumer book, and your staff can open a re-loan on a borrower’s behalf from the customer record that is already there.

• Multi-step online application, mobile-friendly
• Save and resume: borrowers return later through a signed email link
• Two-step pre-qualification before a full application, with criteria set per product
• Embeddable pre-qualification form for your own website, with domain whitelisting
• Application form designer: fields, sections and validation per product
• Camera capture for document upload on mobile, with a visual progress tracker
• Staff can create applications on a borrower’s behalf
• Application pipeline and queue management
• Customer records with import and export

On a small-dollar book the bank file is the underwriting file. The normalised insights view is what makes six providers interchangeable: income, expenses, balance, NSF count, account age and days negative read the same whichever one the borrower’s institution works with, so a scorecard built on pay frequency and NSF history does not have to be rebuilt per provider. Risk-tiered refresh intervals and the monthly budget cap are there because a consumer book is large and every refresh is a billable provider call: a thin-margin payday product can refresh less often than a longer instalment loan, and the cap and its alerts keep that spend visible. Financial-distress monitoring on refreshed data flags an account deteriorating between payments and alerts your staff. Borrowers re-trigger verification themselves from the portal, which a re-loan needs before it can be priced.

• Six bank-verification providers supported, including Flinks, Inverite and ZumRails
• One normalised insights view whatever the provider: income, expenses, balance, NSF count, account age, days negative
• Risk-level badges, income and balance trends, expense breakdown, full accounts and transactions
• Underwriting scorecard derived from verified bank data
• Scheduled refresh by product, with risk-tiered intervals and a monthly budget cap with alerts
• Financial-distress monitoring on refreshed data, with staff alerts
• Borrowers can start or re-trigger verification from their own dashboard
• Duplicate-send protection with separate cooldowns for personal and business requests

Price an instalment product for one province and it may be refused or re-priced in the next. The rules engine holds eligibility, rate caps and stipulations per product and per jurisdiction, so that happens without a second product being configured. Conditional approval with outstanding conditions is the state most small-dollar files sit in (a pay stub still to come, an account still to verify), and the stipulation checklist holds funding until they clear. Decision reasons feed straight into the adverse-action notice: nineteen structured decline reason codes produce the PDF, it goes out by email, and it can be re-sent. Status history records every transition with the staff member who made it and the timestamp, which is what a file review reads back when someone asks why a borrower was declined. Loan notes sit on that same file, so a second reviewer sees the first one’s reasoning.

• Clear lifecycle: Draft, Under Review, Conditionally Approved, Approved, Awaiting Signature, Signed, Funded
• Conditional approval with outstanding conditions
• Rules engine for eligibility, rate caps and stipulations per product and jurisdiction
• Stipulation tracking with required-document checklists before funding
• Status history recording every transition, who made it and when
• Loan notes and internal staff communication on every file
• Decision reasons feed directly into the adverse-action notice

One borrower signs, on a phone, usually within the hour of approval. The built-in e-signature path covers that; DocuSign, SignNow and GoDocs are there for a lender already committed to one, and the local signing path covers a borrower who signs in a branch. Documents generate from your own contract templates, which is where cost-of-borrowing disclosure and cooling-off language live, in French where the borrower is in Quebec. Acceptance timestamps are frozen at the original acceptance and embedded in the signed PDF, so a cooling-off window is dated from the moment the borrower accepted rather than from whenever the file was next touched. Duplicate-agreement and duplicate-notification protection earns its place on a repeat book, where the same borrower signs the same template several times a year and a resent email must not become a second agreement.

• Built-in e-signature, plus DocuSign, SignNow, GoDocs and a local signing path
• Document generation from contract templates, and document OCR
• Three send paths: Send for Signature, Send for Review, Sign as Admin
• Recipient picker for every co-borrower and guarantor, with inline validation
• Acceptance timestamps frozen at the original acceptance and embedded in the signed PDF
• Protection against duplicate agreements and duplicate notifications

Repayment arrives as a pre-authorised debit timed to the borrower’s pay cycle, and most of this group exists to serve that one fact. The schedule calculators and configurable frequencies cover weekly, biweekly and semi-monthly books alongside monthly ones; payment-method detection and the advisory that goes out when a schedule changes keep a borrower’s pre-authorised debit agreement truthful after a reschedule. Automated collection runs with retries and failure handling are the daily shape of a small-dollar book, where an NSF is routine rather than an incident. Mass payment entry covers a day’s receipts posted in one pass rather than one file at a time. Grace periods, late fees and the disclosure that accompanies them are set per product, which is where a product’s fee rules are expressed. Nominal-to-effective conversion and APR calculation feed the cost-of-borrowing figures a consumer contract shows, and payoff quotes and payoff letters are produced on demand for a borrower settling early.

• EFT, ACH, Interac and card rails
• Payment processing through ZumRails, with additional processors available on request
• Seven payment-schedule calculators and configurable frequencies
• Pre-authorised debits, with payment-method detection and an advisory when a schedule changes
• Automated collection runs, retries and failure handling
• Reschedule, hold, restructure and mass payment entry
• Payoff quotes and payoff letters
• Grace periods, late fees and disclosure
• Nominal-to-effective interest conversion and APR calculation

A collector here works a queue, not a caseload. Delinquency tracking and the collections workspace are built for accounts a few days past due rather than a handful of files in default, and the payment-restructuring tools are the first thing a collector reaches for. Reschedule and hold allow repeated reschedules, which is what a borrower on a seasonal or irregular income needs and what a single-use hold cannot cover. Write-off and account-status reporting close out the accounts that do not recover. Communication status tracking records which reminders and which calls have landed on each account, so a second collector picking the file up can see what the borrower has already been told rather than starting the conversation again. None of it leaves the loan file: the notes, the status history and the restructure all sit on the same record.

• Delinquency tracking and a collections workspace
• Payment restructuring tools
• Reschedule and hold, including repeated reschedules for seasonal hardship
• Write-off and account-status reporting
• Communication status tracking on collections activity

Between payments, a consumer borrower lives in the portal, and mostly reaches it through the native mobile app. Balance and schedule on the dashboard, payment history with PDF export, and payoff letters, annual tax statements and monthly statements on demand are the documents a consumer borrower asks for most often. Bank account management (add, view, remove) plus self-service bank verification is what a returning borrower uses before a re-loan, and it is the same verification flow underwriting reads. Reschedule, payoff and restructure arrive from the borrower as requests rather than as decisions, so a hardship conversation starts inside the file instead of on the phone. Everything the borrower does there lands on the same loan file your staff are looking at. For a lender running more than one brand, the portal carries each brand’s own look, so a borrower never signs in to a page naming the wrong one.

• Dashboard with current balance and schedule
• Payment history with PDF export
• On-demand payoff letters, annual tax statements and monthly statements
• Bank account management: add, view, remove
• Self-service bank verification when required
• Reschedule, payoff and restructure requests
• Native mobile app companion

Almost none of this is typed by a person. Email templates for every lifecycle event, plus the payment-due and past-due reminder sequences, carry a small-dollar book: the reminder before a debit, the one after an NSF, the notice that a verification request is waiting. Two-way SMS through Twilio is how a consumer borrower usually replies, and in-app chat and notifications cover the ones already in the portal. Templates are scoped per brand, which matters to a lender running several, and they exist in French for Quebec borrowers alongside English. Notifications for funding holds, verification requests, amended documents and re-review keep the borrower informed through the states a file sits in, rather than only at approval and at funding. Every send is recorded against the file, so a past-due call has the reminder history behind it.

• Email templates for every lifecycle event
• Two-way SMS through Twilio
• In-app chat and notifications
• Payment-due and past-due reminder sequences
• Notifications for funding holds, verification requests, amended documents and re-review

Every item in this group answers to something a provincial regulator can ask to see. Provincial rate-cap enforcement runs in the rules engine per product and per jurisdiction; cost-of-borrowing disclosure and cooling-off tracking run on the dates the file recorded rather than on dates typed in afterwards. Adverse-action notices carry nineteen structured decline reason codes, generate as a PDF, go out by email and can be re-sent, and their reasons come from the decision itself. French-first support for Quebec covers the interface and the contract documents, not a translated covering letter. Audit logs, status history and change tracking run across the loan lifecycle, role-based permissions run across seven roles, and brand-scoped data separation is enforced at query level, which keeps two brands in one instance from reading each other’s borrowers. Encrypted personal data, and webhook signature verification on the payment providers, close the list.

• Adverse-action notices with 19 structured decline reason codes, generated as PDF, emailed, re-sendable
• Provincial rate-cap enforcement
• Cost-of-borrowing disclosure
• Cooling-off period tracking
• French-first support for Quebec: French interface and contract documents
• Audit logs, status history and change tracking across the loan lifecycle
• Role-based permissions across seven roles
• Brand-scoped data separation enforced at query level
• Encrypted personal data, and webhook signature verification on payment providers

Running more than one brand is common in consumer lending, and this group is shaped around it: white-label branding with several brands in one instance, company settings and product configuration per brand, and user and role management across them. Product configuration is where a payday product and an instalment product stop being the same thing: the calculation engine, the fee rules, the schedule frequency and the eligibility criteria are all set there rather than in code. Analytics and reporting read across brands or one brand at a time. The public API is open, and the dedicated-instance option is your own environment, your own data and your own branding, hosted and maintained by us. Every client gets a sandbox to try a product change in before it reaches a borrower, and the platform runs on AWS with continuous deployment.

• Company settings, product configuration, user and role management
• White-label branding, with multiple brands in one instance
• Analytics and reporting
• Public API
• Dedicated instance option: your environment, your data, your branding, hosted and maintained by us
• Hosted on AWS with continuous deployment, and a sandbox environment for every client