Contracts, facility, and financing servicing

Why

Once an offer is accepted, a continuous, tamper-evident thread is needed running from the commitment all the way to repayment — disbursement included — without Tauraco ever touching the funds: the bank disburses directly, the platform documents and reconciles.

How, in the application

Servicing chain. Accepting an offer creates a commitment (Commitment), which freezes the commercial conditions as a cryptographically signed snapshot, in "conditions pending" status — its activation is blocked as long as condition precedents remain open. Once activated, it opens a credit facility, on which drawdowns are requested and then approved, each giving rise to a disbursement following its own states — two of which, distinct and never conflated: "disbursed" is not "confirmed." Tauraco does not record a payment, it receives proof of it, with a mandatory bank reference. The facility's outstanding balance only moves at the moment of that confirmation, under an explicit lock to prevent any lost write in the event of simultaneous payments. Next comes the repayment schedule, then the periodic reconciliation between the outstanding balance calculated by the platform and the balance announced by the bank.

Contracts and signature. The file does not today rest on an electronic signature built into the institutional journey itself: the obligation arises from the offer's acceptance, not from a contractual document signed in the same chain. Two electronic-signature mechanisms otherwise exist on the platform (one multi-party, with a hashed event chain; the other single-signer, with hashed versions) but serve other journeys and are not today wired into the facility-drawdown-disbursement cycle.

Reconciliation. Comparing the outstanding balance derived from the movement register against the balance announced by the bank produces either a match or a variance classified as an exception — never corrected automatically. Resolving an exception requires an explicit resolution note; the original variance stays visible even after resolution, only the status changes.

Safeguards

• The financial-movement register is append-only, guaranteed at three independent levels: a database trigger blocks any modification or deletion, even for the schema owner; application roles hold only read and insert privileges, never update; a closed list of constraints checks the consistency of every entry (non-zero amount, a reason mandatory for any correction).
• An entry is never corrected by modifying it: either a reversing entry offsets it explicitly, or a motivated adjustment entry is added — no function exists to "bring back" a balance to a target figure, which would hide the discrepancy and its cause.
• No outbound payment API exists on the platform side: every disbursement status is today entered manually by the institution itself, and automated checks confirm that no movement ever appears in the portfolio tables inherited from the investor model.