Accueil › Documentation fonctionnelle › API bancaire & Collateral
Menu du document← Accueil
Documentation fonctionnelle
  1. 01Facturation & comptabilité OHADA
  2. 02Pipeline de la facture
  3. 03Demande de financement
  4. 04Analyse de dossier
  5. 05Offres & conditions structurées
  6. 06Position concurrentielle & fourchettes de marché
  7. 07Contrats, facilité et suivi du financement
  8. 08KYB institution
  9. 09Abonnements institutions
  10. 10Collatéral & assiette
  11. 11Tierce détention
  12. 12Alertes & observabilité métier
  13. 13Établissements partenaires et disponibilité
  14. 14Revue juridique
  15. 15IA embarquée
  16. 16Espace entreprise, appels d'offres et veille
  17. 17CRM, candidatures & contrats de marché
  18. 18Ressources humaines & capacité d'exécution
  19. 19Cautions de marché & crédits d'exécution
  20. 20Dossier bancaire, consentement & instruction
  21. 21Décision bancaire, émission & preuve documentaire
  22. 22Collateral documentaire & limites de vérification
  23. 23Droits d'accès, programme Fondateurs & notifications
  24. 24Données et intégrations : exports universels
  25. 25Applications connectées, API publique, webhooks & MCP
  26. 26Connecteurs ERP & synchronisations
  27. 27API bancaire & Collateral
Autres documents
Documentation fonctionnelle

API bancaire & Collateral

Pourquoi

Une banque partenaire qui instruit des dossiers dans le portail bancaire de Tauraco peut vouloir les traiter dans son propre système. L'API bancaire lui permet de raccorder ce système aux dossiers qui lui sont transmis, sans ressaisie. L'entreprise garde la main : seule la désignation d'une banque comme destinataire d'une demande ouvre à cette banque l'accès au dossier.

Comment dans l'application

Créer l'accès de l'établissement. Dans le menu Financement, l'établissement dispose des entrées « Clés d'API de l'établissement » et « Webhooks de l'établissement ». Ces accès sont réservés à un établissement financier et créés par un décideur humain de l'institution. L'application reçoit un rôle de lecteur, ou d'opérateur si elle écrit des demandes de compléments ou des rapprochements ; elle ne reçoit jamais celui de décideur.

Ce que voit la banque.

  • Sa corbeille de dossiers.
  • Chaque dossier tel qu'il a été figé à la soumission, avec une chronologie limitée à sa propre institution.
  • Les pièces du dossier, téléchargées une à une.
  • Les demandes de compléments, qu'elle peut créer et lire, sans pouvoir les clore.
  • Les facilités et les échéances, en lecture, ainsi que le rapprochement d'une facilité et ses écarts.
  • Les garanties Collateral et leur chronologie.

Événements de l'établissement. Les webhooks de l'établissement reçoivent les événements qui le concernent : demande de financement soumise, statut de financement modifié, financement versé, convention signée, garantie inscrite, mainlevée de garantie et événement de test. Leurs charges utiles ne contiennent ni montant ni taux ; le détail se relit par l'API.

Demande retirée. Lorsque l'entreprise retire une demande, son historique (métadonnées, instantané figé et pièces) reste consultable par une banque destinataire. Il est refusé à une banque qui n'était pas destinataire ou qui a décliné. Chaque consultation de dossier et chaque téléchargement de pièce sont tracés.

Côté entreprise. Le propriétaire ERP de l'entreprise (ERP_OWNER), ou un utilisateur au rôle FINANCE, peut exporter le jeu des dépôts Collateral confiés à un tiers détenteur ; chaque ligne porte un avertissement juridique. Par l'API, la lecture de ce jeu exige un accès délégué par un propriétaire ERP.

Garde-fous

  • Aucune décision par API : l'offre, le déclin, le versement, le tirage, la radiation et la mainlevée restent des gestes humains d'un décideur, dans le portail.
  • Une banque ne voit jamais les offres ni les montants internes d'une autre banque, ni le dossier privé d'une garantie.
  • Chaque donnée de garantie porte un rappel : elle n'est pas la preuve juridique d'une sûreté opposable. Seuls les actes et les formalités accomplies auprès du registre compétent font foi.
  • L'ouverture de l'API bancaire suppose le raccordement d'un établissement partenaire habilité ; Tauraco l'active après validation des textes juridiques ci-dessus, qui ne peuvent être reformulés sans nouvelle décision écrite.
  • L'API ne lit aucun compte bancaire et n'initie aucun paiement : l'ordre de virement pain.001 n'est pas pris en charge et le relevé camt.053 reste expérimental.