Home › Functional documentation › Alerts & business observability
Document menu← Home
Functional documentation
  1. 01Invoicing & OHADA accounting
  2. 02Invoice pipeline
  3. 03Financing request
  4. 04File analysis
  5. 05Offers & structured conditions
  6. 06Competitive position & market ranges
  7. 07Contracts, facility, and financing servicing
  8. 08Institution KYB
  9. 09Institution subscriptions
  10. 10Collateral & borrowing base
  11. 11Third-party custody
  12. 12Alerts & business observability
  13. 13Demonstration network
  14. 14Legal review
  15. 15Embedded AI
Other documents
Functional documentation

Alerts & business observability

Why

A financing file or a guarantee can silently deteriorate — a borrowing base gone insufficient, an overdue formality, a negative inspection. This process detects these situations early and routes them to the right person, without ever letting the commercial demo blend with operational reality.

How, in the application

Two alert families cover, on one hand, collateral and security interests (expired registration, uncollected due date, potentially multiple pledge, release not carried out, incomplete or overdue formality, unvalidated legal configuration, insolvency-proceeding risk, negative field check, overdue inspection, expiring or expired mandate, expired cost source) and, on the other, institutional financing servicing (expiring offer, open condition precedents, expiring facility, pending drawdown, upcoming or overdue repayment, insufficient borrowing base, pending disbursement, diverging reconciliation). Each alert carries a severity (information, warning, critical) and a status (open, acknowledged, resolved, or suppressed — never erased: a suppressed alert remains a tracked human decision that the engine respects).

Demo/real isolation. The tenant used to classify an alert or a metric always comes from the authentication token, never from a caller-supplied header that could be forged. A tenant whose class is unknown counts by default as demo — never as real, which would be the dangerous fallback. For institutions, the demo axis lives on the financeur space itself rather than on the technical tenant, because a demo bank still exists as a real tenant on the platform; steering aggregates therefore explicitly exclude demo institutions from their real-world scope, unless explicitly requested otherwise.

An institution's alerts and observability cockpit.
An institution's alerts and observability cockpit.

Safeguards

  • The alert-type vocabulary is locked down to the database level by an explicit constraint, so that an alert type declared on the application side but not recognized by that constraint can never be written silently — such a gap, already observed and corrected, once prevented several alert types from being recorded until it was fixed.
  • No network-wide shared alert can carry sensitive commercial data (rate, advance rate, margin, amount, score, KYB elements) — confidentiality is checked before the write, not after.
  • An alert is never permanently deleted: its resolution or suppression remains an event kept in the file's history.