Principes de conception du registre pour les plateformes de portefeuille

Le registre est le fondement de toute plateforme de portefeuille. Chaque affichage de solde, chaque exécution de réconciliation, chaque rapport réglementaire dépend de l'exactitude du registre. Pourtant, la conception du registre est fréquemment traitée comme un problème de schéma de base de données plutôt que comme une discipline d'ingénierie - et les conséquences apparaissent des mois ou des années plus tard, sous charge ou lors d'un audit réglementaire.

Commencer par l'immuabilité

La propriété la plus importante d'un registre est que les entrées ne sont jamais modifiées ni supprimées. Chaque transaction qui affecte un solde doit créer une nouvelle entrée de registre - jamais mettre à jour une existante. Ce n'est pas un choix de performance ; c'est une exigence de correction.

Les registres immuables permettent la reconstruction du solde à un instant donné. À partir de n'importe quel horodatage, vous devriez pouvoir calculer le solde qui existait à ce moment en additionnant toutes les entrées jusqu'à ce point. Les registres mutables perdent cette capacité et rendent la reconstruction de la piste d'audit impossible.

Dériver les soldes ; ne pas les stocker

Une erreur courante consiste à stocker le solde actuel comme colonne dans l'enregistrement de compte et à le mettre à jour à chaque transaction. Cela crée un solde mutable qui peut dériver de l'historique des transactions à travers des conditions de course, des transactions échouées qui mettent à jour le solde avant de se rollback, ou des bugs dans la logique de mise à jour.

L'approche correcte : le solde est toujours calculé à partir du registre. En pratique, cela est rendu performant avec des points de contrôle de solde - des instantanés périodiques qui représentent le solde confirmé à un moment donné, à partir duquel vous n'avez qu'à sommer vers l'avant.

Voir aussi : Les erreurs d'architecture les plus courantes dans les passerelles de paiement

La comptabilité en partie double comme primitive de correction

Les registres à partie simple suivent débits et crédits indépendamment, ce qui signifie qu'ils ne peuvent pas détecter les incohérences internes. Les registres en partie double exigent que chaque transaction produise des écritures comptables dont la somme est nulle sur les comptes affectés.

Pour les plateformes de portefeuille, cela signifie que chaque crédit sur un compte client a une contrepartie de débit sur un compte flottant ou de passif. Le total de toutes les entrées du système devrait toujours être nul. Lorsque ce n'est pas le cas, il y a un bug.

Cette propriété rend la réconciliation mécanique plutôt qu'investigatrice. Si les livres ne sont pas équilibrés, quelque chose ne va pas. S'ils sont équilibrés, vous avez un haut degré de confiance dans la correction du système.

Idempotence au niveau du registre

Chaque opération de création d'entrée doit être idempotente. Cela signifie : les clients fournissent une clé d'idempotence avec chaque requête, le registre stocke cette clé avec l'entrée, et les requêtes en doublon avec la même clé retournent le résultat original sans créer de nouvelle entrée.

Sans cela, les nouvelles tentatives réseau - qui sont garanties de se produire dans tout système distribué - créent des entrées en doublon. Les entrées en doublon corrompent les soldes et génèrent des échecs de réconciliation coûteux à investiguer et à corriger.

Voir aussi : Construire des APIs de paiement idempotentes

Gestion des mises à jour de solde concurrentes

Les conditions de course dans les mises à jour de solde sont la source de la plupart des incohérences de registre. Deux transactions concurrentes qui lisent toutes les deux le même solde et appliquent toutes les deux un débit peuvent aboutir à un solde incorrect d'exactement une transaction.

La correction appropriée dépend de vos exigences de cohérence. Le verrouillage pessimiste (SELECT FOR UPDATE) est simple mais limite le débit. Le contrôle de concurrence optimiste (comparer-et-échanger sur une colonne de version) fonctionne bien pour les charges de travail en lecture intensive. L'event sourcing - où les transactions s'ajoutent à un journal d'événements et les soldes sont dérivés - découple le débit d'écriture de la cohérence de lecture.

Comptes de règlement et gestion du flottant

Les fonds clients dans une plateforme de portefeuille doivent être suivis à deux niveaux : le solde notionnel du client (ce qu'il croit détenir) et les fonds réels en garde (ce que votre plateforme détient dans des comptes bancaires ou auprès de prestataires de paiement).

Ces deux chiffres doivent se réconcilier. Concevez votre registre pour suivre les deux, avec des comptes de règlement explicites représentant les fonds en transit, les fonds en attente de confirmation et les fonds dans chaque compte de garde. C'est ce qui rend les rapports réglementaires tractables et ce qui vous permet de détecter les écarts avant qu'ils ne deviennent des réclamations.

Exigences de piste d'audit

Les régulateurs exigent que chaque changement de solde soit attribuable à une transaction spécifique, que les soldes historiques soient reconstructibles, et que la piste d'audit soit inviolable. Un registre immuable en partie double avec des clés d'idempotence et une journalisation complète des événements satisfait à ces exigences par conception.

Avant de concevoir votre piste d'audit, comprenez les exigences réglementaires spécifiques dans votre juridiction. La CBUAE, la FCA et la BaFin ont des exigences différentes en matière de tenue de registres et de rapports qui affectent le modèle de données.

---

Les erreurs de conception du registre sont coûteuses à corriger après coup. Si votre plateforme présente une dérive de solde, des échecs de réconciliation ou des lacunes dans la piste d'audit, une évaluation de plateforme est le moyen le plus rapide de comprendre l'étendue du problème et le chemin de remédiation.

Notre service d'ingénierie de plateforme wallet couvre la conception du registre, la gestion des soldes et l'architecture de règlement pour les fournisseurs de wallets en MENA et en Afrique.