Decisions you can explain afterwards.
In financial services every automated decision has to be defensible months later. iLeaf builds lending, payments and risk systems where the reasoning is recorded, not just the result — including Letshego's digital lending work and Kotlin Multiplatform fintech applications, plus contract intelligence over binding agreements.
Ask Lia about financial servicesWhat this includes
- Digital lending
- Origination, eligibility and decisioning flows, with the reasoning behind each outcome captured.
- Payments & wallets
- Payment flows and mobile wallets, including cross-platform delivery with Kotlin Multiplatform.
- Risk & fraud
- Anomaly detection and scoring that flags for review rather than declining silently.
- Contract intelligence
- Graph-RAG over agreements, so obligations, amendments and renewal dates are queryable and cited.
- Explainability
- Every automated decision reconstructable with its inputs and rationale, for regulators and disputes.
- Predictive analytics
- Forecasting on portfolio, collections and churn, evaluated against held-out outcomes rather than backfitted.
How we run it
Every phase ships something usable on its own, so you are never holding a half-finished system waiting on the next milestone.
Assume the decision will be challenged
Architecture starts from what a regulator or a customer will ask in six months, and works backwards.
Keep humans on the adverse cases
Automation approves the clear cases; anything adverse routes to a person with the evidence assembled.
Separate the model from the policy
Business rules stay explicit and auditable rather than being absorbed into a model nobody can interrogate.
Prove it on history
Decisions are replayed against historical cases with known outcomes before anything goes live.
What we build it with
- Kotlin Multiplatform
- Swift
- Node.js
- Python
- PostgreSQL
- Neo4j
- Graph-RAG
- XGBoost
- AWS
- Terraform
- Governor Engine
- OpenTelemetry
Questions we get asked
Can you make AI decisions auditable?
Yes, and in this sector it is the requirement rather than a feature. Every run records inputs, model and prompt versions, reasoning, and outcome, retained so a decision can be reconstructed later. Business policy is kept explicit and separate from the model, so rules can be shown rather than inferred.
How do you approach fraud detection?
As a flagging problem, not an automatic-decline one. Models surface anomalies with the signals that triggered them, and a person decides on the borderline cases. That keeps false positives from silently costing you good customers, and keeps the decision defensible.
What fintech experience do you have?
Digital lending with Letshego across multiple African markets, Kotlin Multiplatform fintech applications, payments and wallet work, and contract intelligence over binding financial agreements — alongside fifteen years of general platform engineering.
Let’s talk about financial services.
Tell us what you are running and what it needs to do next. We will tell you honestly whether we are the right team for it.
