Why the guarantees belong in the database
Application checks answer "did we remember here". That question accumulates with every endpoint you add.
Holding funds would make Renny easier to sell and much harder to adopt.
An obvious product extension for a verification platform is to move the money too. Hold the loan proceeds, release on authorization, reconcile automatically. It is a clean story and it is a larger business.
We do not do it, and the reason is that it would make Renny harder for a lender to adopt while making the core product no better.
None of that improves the evidence. Each item is a reason for an adoption decision to take another quarter.
An authorization and a record. Renny says a disbursement is supported by complete evidence, and you pay on your own rails, on your own schedule, through the systems you already reconcile. We record what you tell us moved, against the authorization that permitted it, in an append-only ledger used for reconciliation rather than for movement.
There is nothing of yours for us to lose, freeze, or misapply. That is not a limitation of the current version.
You keep the operational work of disbursement, and you keep the timing risk that a payment goes out late. We are not going to claim that is a feature for you — it is a genuine cost of this design.
What you get for it is that adopting a verification layer is a technology decision rather than a treasury decision, and that the failure of your vendor is an inconvenience rather than an incident. For a lender evaluating an early-stage provider, we think that trade is the right one, and we would rather be clear about which side of it we are on.
When a vendor proposes holding your funds, price the diligence, not just the software.
Pick a closed project. We will show you the document you would hand a regulator. If it does not answer the question, nothing else matters.