Protocol - Signatures
Cette page décrit Signatures au niveau protocolaire afin de stabiliser les échanges entre partenaires, banques et systèmes de clearing.
Guides de référence pour comprendre le protocole Omniban, créer des instruments financiers, appliquer les contrôles de conformité et connecter les partenaires bancaires au clearing.
Version actuelle : 0.1.0-alpha. Cette page est prête dans la structure de navigation. Le contenu détaillé peut maintenant être enrichi sans casser les URLs publiques.
Version actuelle : 0.1.0-alpha. La documentation publique est en préparation; cette page fixe la structure UX avant l'intégration complète des contenus techniques.
Signatures
Cette page décrit Signatures au niveau protocolaire afin de stabiliser les échanges entre partenaires, banques et systèmes de clearing.
Utilisation
Cette section décrit comment utiliser Protocol pour Signatures dans un environnement partenaire Omniban.
Exemple
Exemple minimal de structure pour préparer l’intégration et garder une base cohérente entre les SDK.
{
"technology": "protocol",
"menu": "transport",
"page": "signatures",
"status": "draft-ready"
}Étapes suivantes
Compléter les détails métier, les paramètres acceptés, les erreurs possibles et les scénarios de test pour cette page.
Vue d'ensemble
Omniban est une couche protocolaire pour les instruments financiers. Elle standardise la création, la vérification, le routage et le règlement d'un instrument entre acteurs bancaires, fintechs, agents de conformité et opérateurs de corridor.
Pourquoi Omniban existe
Les flux financiers transfrontaliers restent fragmentés : formats propriétaires, contrôles répétés, délais longs et visibilité limitée. Omniban ramène ces étapes dans un flux protocolaire unique, avec un instrument qui transporte ses propres données financières, réglementaires et de settlement.
Acteurs du réseau
Le réseau Omniban distingue les émetteurs, bénéficiaires, banques partenaires, agents de conformité, opérateurs de corridor et agents de règlement. Chaque acteur intervient selon son rôle, ses permissions et son profil réglementaire.
Architecture du protocole
Le protocole organise le flux autour de quatre couches : l'instrument, le contrôle de conformité, le routage juridictionnel et le settlement. Cette séparation permet à une banque ou une fintech d'intégrer Omniban sans réinventer tout le pipeline de compensation.
Omniban Instrument
L'instrument est l'unité centrale du protocole. Il contient l'identité des acteurs, le corridor, le montant, les devises, les résultats de conformité, les métadonnées de routage et les instructions de règlement.
{
"type": "cheque",
"corridor_code": "GN_BANKING",
"instrument_id": "ins_01hv...",
"state": "SUBMITTED",
"compliance": {
"status": "PENDING",
"risk_score": null
},
"settlement": {
"method": "bank_clearing",
"deadline": "J+1"
}
}Cycle de vie
Un instrument passe par des états successifs : création, soumission, vérification, clearance, routage, règlement puis confirmation. Chaque transition est historisée pour produire une trace d'audit complète.
Check Module
Le Check Module applique les contrôles KYC, AML, sanctions, limites transactionnelles et règles juridictionnelles. Son résultat voyage avec l'instrument afin d'éviter les vérifications redondantes entre partenaires.
Règles juridictionnelles
Les règles ne sont pas globales par défaut : elles sont chargées selon le pays, le corridor, le type d'instrument et les contraintes du régulateur local.
Scoring & risques
Le score de risque agrège les signaux d'identité, de comportement, de limites, de sanctions et d'historique afin de décider si un instrument peut continuer, être suspendu ou être rejeté.
API Reference
L'API Omniban permettra aux partenaires de créer un instrument, consulter son statut, récupérer son résultat de conformité, lancer le settlement et recevoir des événements temps réel via webhooks.
Java SDK
La documentation Java décrira la création d'instruments, la signature HMAC des requêtes, l'idempotence et la consommation des webhooks dans les environnements bancaires JVM.
PHP SDK
Le SDK PHP ciblera les backends Laravel, Symfony et applications PHP classiques pour soumettre des chèques, suivre les états de clearing et journaliser les résultats du Check Module.
JavaScript SDK
La couche JavaScript servira aux interfaces partenaires, tableaux de bord, formulaires de capture et outils de suivi temps réel autour des instruments Omniban.
Laravel Package
Le package Laravel pourra fournir une configuration prête à l'emploi, des jobs de webhook, des notifications, des migrations de journalisation et des helpers pour signer les appels API.
Node.js SDK
Le SDK Node.js couvrira les intégrations Express, NestJS et workers server-side pour piloter les instruments, automatiser le routing et recevoir les événements de settlement.
Spring Boot Starter
Le starter Spring Boot sera pensé pour les institutions bancaires : configuration typée, filtres de signature, clients HTTP, retries idempotents et observabilité des instruments.
Webhooks
Les webhooks notifient les partenaires à chaque événement important : instrument créé, vérifié, routé, réglé, confirmé, rejeté ou suspendu.
Sandbox
Le sandbox permettra de simuler la création d'instruments, les résultats de conformité, les transitions d'état et les callbacks sans mouvement réel de fonds.
Corridors
Le premier axe produit met en avant la gestion des chèques et le clearing bancaire en Guinée. Les corridors internationaux pourront ensuite s'ajouter avec leurs propres règles de conformité, devises, limites et partenaires de règlement.