Ce que la fintech exige du développement de logiciels SaaS et produits

La fintech n'est pas une version plus difficile du SaaS. C'est une discipline différente, et traiter cela comme une amélioration du développement de logiciels SaaS et produits ordinaires est la façon dont les équipes finissent par livrer des systèmes qui passent l'assurance qualité mais échouent les audits. Les effondrements des middleware BaaS de 2024 l'ont rendu concret. Plusieurs plateformes qui semblaient solides de l'extérieur se sont avérées avoir des problèmes de justesse enfouis dans leurs couches de transactions, des problèmes qui n'ont fait surface que sous l'examen réglementaire ou à charge maximale. Je construis des systèmes financiers depuis assez longtemps pour avoir des opinions sur les raisons pour lesquelles cela continue de se produire.

La justesse est une contrainte, pas un objectif

Dans la plupart des travaux produits, la justesse est quelque chose que vous visez. En fintech, c'est le minimum. Une fonctionnalité qui fonctionne quatre-vingt-dix-neuf fois sur cent est un bug dans un contexte de paiements, pas une statistique dont être fier. La distinction importe parce qu'elle change la façon dont vous concevez. Vous cessez de vous demander si une chose fonctionne et commencez à vous demander ce qui se passe quand elle ne fonctionne pas, et si le système peut se rétablir sans perte de données ou double traitement.

La plateforme de services financiers que j'ai construite a réduit les temps de réponse de trente pour cent, mais ce chiffre n'est pas le point. Le point est que nous l'avons réalisé sans toucher aux garanties de justesse sur l'état des transactions. La vitesse et la justesse ne sont pas en opposition si vous séquencez le travail correctement. La plupart des équipes échangent l'une pour l'autre parce qu'elles les traitent comme des préoccupations concurrentes plutôt que comme des préoccupations en couches.

L'idempotence n'est pas optionnelle

Chaque opération de paiement doit être idempotente. Cette phrase est approuvée dans les examens d'architecture et puis silencieusement ignorée quand la pression des sprints augmente. Le résultat est des frais en double, des inversions manquées, et des cauchemars de réconciliation qui prennent des semaines d'ingénierie à démêler.

Les clés d'idempotence, la livraison au moins une fois avec déduplication au consommateur, et les machines d'état explicites pour le cycle de vie des transactions ne sont pas des motifs avancés. Ce sont les enjeux minimaux. La raison pour laquelle ils sont ignorés est qu'ils ralentissent la construction initiale et rendent le chemin heureux plus difficile à démontrer. C'est un échec de priorisation, pas un échec technique.

Quand j'ai défini la portée de la plateforme de paiements, l'idempotence était dans le premier sprint, pas une phase de durcissement ultérieure. Cette décision a économisé des semaines de réponse aux incidents plus tard. Rétrofiter la justesse dans un système financier en direct est coûteux d'une manière qu'il est difficile d'expliquer à un stakeholder qui a approuvé les raccourcis originaux.

La piste d'audit fait partie du produit

Les régulateurs n'auditent pas vos fichiers Figma. Ils auditent vos journaux, votre historique d'événements, et votre capacité à reconstruire ce qui s'est passé pour une transaction donnée à un moment donné. Si votre système ne peut pas répondre à cette question en quelques minutes, vous avez un passif de conformité, pas seulement un écart d'outillage.

Cela signifie que la piste d'audit n'est pas une fonctionnalité de journalisation que vous ajoutez à la fin. C'est une structure de données de première classe. Des tables d'événements en ajout seul, des enregistrements immuables, des horodatages avec contexte de fuseau horaire, l'attribution d'acteur sur chaque changement d'état. Ce sont des décisions architecturales qui doivent être prises avant d'écrire votre premier endpoint, parce que les changer plus tard signifie migrer les données de production sous charge.

La construction OptimalTax pour les déclarations fiscales automatisées a atteint quatre-vingt-dix-neuf pour cent de précision de calcul, et ce chiffre repose entièrement sur le fait d'avoir une piste d'audit fiable en dessous. La précision est la sortie. La piste d'audit est ce qui rend la sortie vérifiable. Ce sont des choses différentes, et les deux importent.

Les motifs de développement de logiciels SaaS et produits que la fintech casse

Les motifs SaaS standard sont optimisés pour la vitesse d'itération. La fintech en casse plusieurs.

• —Les suppressions logicielles sont un passif dans les enregistrements financiers. Les lignes supprimées qui sont juste marquées peuvent être démarquées. Utilisez plutôt des enregistrements immuables et des champs de statut explicites.
• —La cohérence éventuelle est correcte pour un flux de notifications. Ce n'est pas correct pour un solde de compte. Sachez quelles parties de votre système ont besoin d'une cohérence forte et appliquez-la là.
• —Les drapeaux de fonctionnalités sur les flux de paiement doivent être traités avec un soin extrême. Un drapeau qui achemine certains utilisateurs vers un nouveau chemin de paiement peut créer des problèmes d'état divisé dans votre grand livre si l'état du drapeau n'est pas capturé dans l'enregistrement de transaction.
• —Les tâches de fond sans idempotence sont un risque de double traitement. Chaque tâche qui touche l'argent doit être sûre d'être exécutée deux fois.

Aucun de ces éléments ne sont des préoccupations exotiques. Ce sont les conséquences ordinaires de l'application de la pensée de vélocité SaaS à un domaine où le coût d'une erreur n'est pas une mauvaise expérience utilisateur mais une erreur financière avec une piste écrite.

L'analytique en temps réel sans compromettre le chemin d'écriture

Les produits fintech ont de plus en plus besoin de tableaux de bord en temps réel, de signaux de fraude, et d'analytique de dépenses. La tentation est de lire directement à partir de la base de données transactionnelle. Cela fonctionne jusqu'à ce que ce ne soit pas le cas, et quand cela cesse de fonctionner, cela fait tomber le chemin d'écriture avec.

La séparation correcte est une architecture pilotée par les événements où le système transactionnel émet des événements et la couche d'analytique les consomme de manière asynchrone. La base de données transactionnelle reste optimisée pour les écritures et les recherches ponctuelles. Le magasin d'analytique, qu'il s'agisse d'une base de données en colonnes ou d'une couche d'agrégation en continu, gère les requêtes lourdes en lecture. Vous payez un petit coût de latence du côté analytique. Vous protégez la chose qui ne peut pas tomber en panne.

J'utilise ce motif de manière cohérente sur les constructions fintech parce que l'alternative, une base de données partagée servant les deux charges de travail, a un mode de défaillance qui est disproportionné par rapport à la commodité qu'elle offre.

Ce que cela signifie pour un fondateur qui construit en fintech

Si vous êtes au stade MVP et que vous construisez un produit financier, les décisions que vous prenez dans les huit premières semaines détermineront si vous pouvez évoluer, passer la diligence raisonnable, et survivre à un audit de conformité douze mois plus tard. Ce n'est pas une raison de sur-ingénierie. C'est une raison de faire les bonnes choix fondamentaux tôt, ce qui est une chose différente.

Le travail que j'ai fait dans les constructions fintech et secteur public montre un motif cohérent : les équipes qui se sont déplacées le plus rapidement à long terme étaient celles qui traitaient la justesse comme une contrainte dès le premier jour, pas une préoccupation de phase deux. Les équipes qui l'ont reportée ont passé ce temps deux fois.

Si vous définissez la portée d'un produit financier et que vous voulez un deuxième avis sur l'architecture avant de vous engager dans une direction, l'engagement MVP Sprint est conçu exactement pour ce moment. Huit à douze semaines, portée fixe, avec les décisions fondamentales prises d'une manière qui tient plus tard. Vous pouvez aussi me contacter directement à /#contact si vous voulez d'abord discuter d'une contrainte spécifique.