Channels & Deployment

Loan Management System

The borrower-facing channel. Applicants apply, pay and run follow-on transactions themselves, against the same Lending Management System that services every other channel.

Registration through to collections runs without a company employee touching the transaction. A borrower can hold several loan types at once, each handled to closure.

Key features

  • Customized website(s) — tailored to match the brand identity of our clients.
  • Online Loan Applications — interacted loan applications built into the websites.
  • Loan types — payday, installment, title & line of credit in one line of business.
  • Fax Processes — end-user-configurable fax loans & fax-less loans related processes.
  • Integrations — integration to multiple credit bureaus & credit-scoring via Teletrack, Veritec, Lexis Nexis, CL Verify or Selling Source integration with a customizable internal underwriting matrix.
  • Complete eSignature management & document-management system.
  • Unique convergence model — customers flow directly into brick-and-mortar store central database for convenient transaction handling.
  • Complete integration with existing processes including payroll, finance & accounting, HR, third-party collections, etc.
  • Comprehensive analytical & transactional reporting structure including dashboard functionality for management views and ad-hoc reporting for analysis.

Administrative Module

  • Document Management Configuration
  • Lead Generation Management
  • Employee Management
  • Banking information management to manage ACH processes
  • Privilege & Rule-Set Management
  • Collections & Reporting

Customer Interface Module

  • Borrower Registration Management
  • Document Presentment & Management
  • eSignature Management
  • Refinance / Renewal request management
  • Password & Account Management / Inbox
  • Alterable loan product offerings

Internet Loan Processing Module

The interface available to loan-processing & collections representatives to enable originating loans & servicing loans originated for various transactions — Customer Management, Document Management, Loan Processing, ACH & Returns Management, Collections Management and Reporting.

Point of Sale (POS)

The counter channel: a Point-of-Sale application for borrower transactions plus a lending management layer for administrators and store staff. Both use the same modern screen layout as the rest of QFund, so counter and back office are one interface rather than two applications — and a new store employee serves customers on their first shift (one interface, every module).

Covers the whole life cycle, from issuing a loan to collections. Smaller operators can run the same application on the QFund™ Multi-Tenant model — a logically separated tenant on shared infrastructure (ASP only), which lowers cost of ownership without cutting the application down.

The QFund™ Storefront application is the application variant that enables loan processing and management at the physical stores of an organisation where a borrower walks into the store to receive services from the CSRs of the store.

Administrative Module

  • Stores management
  • Business-rules management
  • Fee management
  • Store Promotions management
  • Store Employee management
  • Privileges management
  • Administrative transactions & Admin Reports

Store Front Module

  • Borrower / Customer management
  • Store Cash management
  • Loan Transaction processing
  • Daily Reconciliation processing
  • Store Employee management
  • Collections management
  • Administrative transactions & Store Reports

Loan products by store & by brand

Which loan products a location may write, and on what fee structure, is configuration. Several loan products of the same loan type can run across the network at once — each enabled for the brands, channels, states and stores you choose — so a new product or fee band can be piloted in a handful of stores first. Store-level receipts, agreements and authorisation letters come from your own templates.

Omni Channel

One hybrid deployment for lenders running both models: the POS application in stores, QFund™ Online for the internet, and a converged database so a customer is the same customer on either. QFund™ runs this model for several of the largest operators in the sector.

QFund™ has been successful in offering this model to some of the large clients in the short-term financial services industry.

Channel is one of the dimensions a loan product is configured against, so one core supports a counter-only product, an online-only one, and one offered through both on different fees — all against one borrower record and one balance. Re-scoping any of them is configuration and testing.

APIs & headless — bring your own front end

The three deployments above are QFund’s own channels. The fourth option is to use none of them: every function QFund performs is exposed as a RESTful JSON API over HTTPS, so a lender can present its own experience and use QFund purely as the lending core.

This is the model for lenders with a development team and a view of their own on what the borrower journey should look like — or with an agent tool and a CRM their staff already live in. QFund stays the system of record: one borrower, one balance, one audit trail, whichever front end wrote the transaction.

  • Your own online portal or mobile app against QFund’s verification, decisioning, schedules, interest, fee and ledger logic — none of the lending maths moves into your code.
  • Your own agent or CSR interface, with QFund behind it as the LMS core only, if you would rather not move your staff onto new screens.
  • Both at once: a portal on the API while your stores run the QFund POS, on one converged database.
  • Token credentials issued per integration and scoped to a QFund permission set, so a borrower-portal token and a back-office token do not carry the same rights.
  • Webhooks on loan and payment events — decisioned, funded, payment posted, payment returned, promise broken, status changed — so your systems react as it happens rather than on a nightly file.
  • The same state rule sets, permissions and audit trail as the equivalent screen action: an integration cannot write a loan a CSR would have been stopped from writing.
  • Platform configuration — loan products, fees, rate tables, state rule sets, document templates, users — is performed in QFund’s admin interface, not through the API.

Full coverage detail is on the platform API layer section, and interfaces to systems outside the pre-built set are handled through integration services.

CSO — Credit services organisations

Credit services organisations are licensed to arrange loans for individual customers who are generally underserved by banks and who have a poor credit rating. For a fee, these organisations help those customers obtain an extension of credit, or improve their credit history or rating.

QFund™ supports users operating as a CSO for a third-party lender, maintaining normal loans and CSO loans side by side — payday and installment in both cases — controlled by a set of business rules.

  • Allow CSO control to specify whether CSO loan can be issued for the specific state or not.
  • Maximum ACH — specifies the maximum number of times ACH can be performed on a loan.
  • ACH deposit days — number of grace days from the due date after which ACH can be performed.
  • MaxACHCount — maximum number of times the CSR can perform ACH.
  • Minimum Interest Amount — specifies the minimum interest amount that the customer has to pay while making Early Payoff.
  • Number of instalments due for ACH — specifies the number of instalments to be due for processing ACH.
  • Written-off days — specifies the number of days after which the deal is written off due to inactivity after ACH is return-posted.