Do you provide the credit scorecard or lending policy?
No. Your credit policy, scorecards, affordability rules, and risk appetite are yours, and they are commercially and regulatorily specific to you. We build the engine that applies them consistently, versions them, retains the evidence, and lets you test a proposed change against historical applications before releasing it. If you do not yet have a documented policy, that needs resolving with your own credit and compliance people before software can help.
Is AgileTech a lender or a licensed credit firm?
No. We are a software engineering company holding ISO 9001:2015 and ISO 27001:2013 certifications and no financial services or lending permission of any kind. We do not lend, do not hold funds, and do not provide credit, legal, or regulatory advice. All permissions and obligations remain yours.
Which is harder, origination or servicing?
Servicing, consistently, and it is consistently underestimated. Origination is a bounded flow that ends in a decision. Servicing runs for years through repayments, missed payments, restructures, rate changes, early settlements, and disputes, each of which must post correctly and reconcile. When a lending platform is in trouble, the problem is nearly always in the servicing ledger.
Can you support peer to peer or marketplace lending?
Yes. It adds an investor side to the ledger: loan parts allocated to funders, receipts distributed proportionally, fees applied per your model, and statements that reconcile exactly for every investor. Whether operating such a platform requires specific permissions depends entirely on your jurisdiction, and that is a question for your legal advisers rather than for us.
How do you make sure interest calculations are right?
Integer minor unit arithmetic with an explicitly defined day count convention and per product rounding rules, validated against worked examples that your finance and compliance teams produce and verify independently of us. Then continuous reconciliation between the stored schedule and actual charges, so any drift surfaces immediately instead of accumulating quietly across a book.
What happens when a customer pays the wrong amount?
It is treated as a normal case rather than an exception, because it is normal. Underpayments, overpayments, early payments, and duplicate payments each have defined behaviour, and allocation across interest, fees, and principal follows the product's configured order. Every allocation posts to the ledger with its cause, so a customer question about where their money went has a precise answer.
How do you handle arrears and vulnerable customers?
Arrears follow staged strategies with contact history, promise to pay tracking, and payment plan and forbearance arrangements that carry their own interest and fee treatment. Vulnerability and hardship flags constrain what the system will permit, not merely what it displays, so a flagged customer cannot inadvertently receive an inappropriate action. The specific treatment rules are yours to define; we make them enforceable and evidenced.
Can you migrate our existing loan book?
Yes, and it is planned as its own workstream rather than folded into the build. Every loan must reconcile exactly before and after migration, the schedule the new system computes must match what the customer already holds, and the process is rehearsed against production shaped data with a defined rollback. Migration is where these programmes most often go wrong, so it gets disproportionate attention.
How long does a lending platform take to build?
A single product with automated decisioning, servicing, and collections is typically several months, with product definition and the accounting core taking a substantial share of that. Multiple products, secured lending, broker channels, investor funding, or migration of an existing book extend it considerably. We give a range after the product and convention definition step, because that is when the real complexity becomes visible.
Do you integrate with credit bureaux?
Yes, both enquiry and performance reporting back to the bureau. The important design detail is that the raw bureau response is retained against the decision rather than only the derived score, because a future dispute or audit turns on what the bureau actually said at that moment. Consent capture and search footprint handling are built in from the start.
What do you need from us to start?
Documented product terms including rate, term, fees, day count convention, and allocation order; your credit policy and affordability approach; your collection rails and bureau arrangements; expected volumes; and whether an existing book will migrate. If a book exists, a data extract and a handful of loans with their full transaction history tell us more than any specification document.
