Comprendre les paiements comme un système distribué critique.
Un parcours conçu pour te permettre d'expliquer les flux, raisonner sur les états, diagnostiquer un incident et relier ton expérience des API et systèmes embarqués aux métiers bancaires.
Objectif d'entretien
À la fin, tu dois pouvoir prendre un paiement inconnu et répondre méthodiquement : qui agit, quel message circule, quel contrôle décide, quel état est persisté, qui porte le risque, comment prouver ce qui s'est passé et comment réparer.
Ton angle de crédibilité
Tu ne prétends pas avoir dix ans de banque. Tu montres que tu sais transférer des compétences de systèmes critiques.
API contractuellesmachines à étatstraçabilitévalidationincidentscoordination multi-acteursLe modèle mental fondamental
Les 4 plans
La question qui évite 80 % des erreurs
« Est-ce que je parle du transport du message, de la décision métier, de la comptabilisation ou du règlement final ? »
Un message « accepté » peut seulement signifier qu'il est techniquement reçu. Une autorisation carte n'est pas encore le règlement au commerçant. Un virement envoyé n'est pas nécessairement crédité. Une interface peut afficher un statut obsolète alors que le ledger a changé.
Les invariants à protéger
Conservation de valeur
Pas de création ou disparition d'argent entre les ledgers, comptes de règlement et écritures de frais.
Unicité économique
Un retry réseau ne doit pas produire deux débits. On vise un effet économique unique, même si plusieurs messages sont reçus.
Auditabilité
Toute décision doit être reconstruisible : demande, contexte, règle, réponse, acteur, horodatage et version.
Architecture métier d'un paiement carte
Porteur
S'authentifie, consent, reçoit l'information et peut contester.
Commerçant
Déclenche l'acceptation, livre le bien et conserve les preuves.
Acquéreur
Onboarde le commerçant, collecte les transactions et lui reverse les fonds.
Réseau
Routage, règles, standards, calcul de positions et mécanismes de litige.
Émetteur
Émet la carte, authentifie, autorise, débite et gère le risque porteur.
Issuing vs acquiring
| Issuing | Acquiring | |
|---|---|---|
| Client principal | Le porteur de carte | Le commerçant |
| Responsabilités | Émission, authentification, autorisation, limite, relevé, contestation | Acceptation, terminal/API, collecte, paiement du commerçant, risque marchand |
| Risques typiques | Fraude porteur, crédit, compromission, faux positif | Fraude marchand, chargebacks, blanchiment, faillite avant livraison |
| KPI | Taux d'autorisation, fraude, activation, coût de service | Taux d'acceptation, disponibilité, chargeback ratio, délai de versement |
Autorisation, clearing, settlement et après-vente
But
Décider en quelques centaines de millisecondes ou secondes si l'opération peut être acceptée. L'émetteur vérifie notamment la validité, les fonds ou la limite, les règles de risque et le besoin d'authentification.
Résultat
Approbation avec code d'autorisation, refus avec code de motif, ou demande d'action supplémentaire. Une réservation peut être créée ; ce n'est pas encore le débit définitif.
Le clearing associe la transaction présentée par le commerçant à l'autorisation et prépare les positions. Les fichiers ou messages contiennent les références nécessaires à la facturation, aux frais et aux litiges.
La finalité dépend du système de règlement. Les écritures de comptes clients, de comptes internes et de trésorerie doivent être cohérentes avec le règlement.
Le chargeback est une rétrofacturation encadrée par les règles du réseau. Le porteur conteste, l'émetteur qualifie le motif, l'acquéreur sollicite le commerçant, puis les parties échangent des preuves. Ce n'est pas un simple « remboursement API ».
La réconciliation rapproche plusieurs vérités : demandes d'autorisation, captures, clearing réseau, règlement, ledger, versements marchands et frais. Les écarts sont placés dans des files d'exception avec propriétaire, ancienneté et règle de résolution.
La machine à états carte
Virements et prélèvements SEPA
SEPA Credit Transfer
Virement initié par le débiteur. Traitement non instantané, souvent en cycles ou fenêtres de clearing. Adapté aux paiements ordinaires.
SEPA Instant
Virement en euros 24/7/365 avec disponibilité des fonds en principe sous dix secondes. La décision fraude doit donc être automatisée et prise avant l'envoi.
SEPA Direct Debit
Prélèvement initié par le créancier sur la base d'un mandat. Core vise notamment les consommateurs ; B2B suit des règles distinctes.
Acteurs
Initiation → validation → compensation → règlement
Rejet, retour, recall, remboursement
| Terme | Moment | Sens | Idée clé |
|---|---|---|---|
| Rejet | Avant exécution ou settlement | Le paiement n'aboutit pas | Format, compte, fonds, contrôle ou règle du schéma. |
| Retour | Après une étape d'exécution | Les fonds repartent vers l'origine | Par exemple compte clos ou impossibilité de créditer. |
| Recall | Après envoi d'un virement | Demande de récupération | Ce n'est pas une annulation garantie ; le résultat dépend du statut et de la coopération en aval. |
| Remboursement | Selon droits et schéma | Restitution au payeur | En SDD Core, les droits du débiteur sont plus structurants que dans un virement poussé. |
ISO 20022 au niveau conceptuel
Ce que c'est
Un standard de modélisation de messages financiers avec un dictionnaire de données, des processus métier et des définitions de messages. La syntaxe XML est fréquente, mais l'essentiel est la sémantique partagée.
Pourquoi c'est utile
Données plus riches, contrôles plus précis, automatisation du rapprochement, meilleure traçabilité et interopérabilité. Mais chaque schéma définit son profil d'usage et ses contraintes.
Familles à reconnaître
| Préfixe | Zone | Exemples conceptuels |
|---|---|---|
| pain | Payment initiation | Client → banque : ordre de paiement, statut client. |
| pacs | Payments clearing & settlement | Banque → banque / infrastructure : transfert et statut interbancaire. |
| camt | Cash management | Relevés, notifications, investigation, demandes d'annulation ou réponses. |
DSP2, DSP3, PSR, IPR et DORA
DSP2 / PSD2
Socle actuel des services de paiement : droits et obligations, ouverture des comptes aux TPP, authentification forte, sécurité et responsabilité.
DSP3 / PSD3
Future directive centrée notamment sur l'agrément et la supervision des établissements de paiement et de monnaie électronique.
PSR
Futur règlement directement applicable portant davantage les règles de conduite, la lutte contre la fraude, la transparence et l'open banking.
Instant Payments Regulation
Texte distinct, déjà en vigueur. Il impose progressivement l'envoi et la réception de virements instantanés en euros, des frais non supérieurs aux virements ordinaires comparables et une vérification du bénéficiaire. Pour les banques de la zone euro, les principales échéances d'envoi/réception sont passées en 2025.
DORA
Cadre de résilience opérationnelle numérique applicable depuis janvier 2025 : gouvernance du risque ICT, incidents, tests de résilience, tiers technologiques et partage d'information. Pour un poste paiements, il renforce l'importance des runbooks et des preuves.
DSP2 : ce qu'un recruteur attend
SCA
Authentification forte reposant sur au moins deux catégories indépendantes : connaissance, possession, inhérence, avec liaison dynamique lorsque requise.
Open banking
AISP accède à l'information de compte ; PISP initie un paiement avec consentement. L'ASPSP tient le compte et expose une interface sécurisée.
Responsabilité
La question n'est pas seulement « qui a codé ? » mais « qui avait l'obligation de prévenir, détecter, informer et rembourser ? ».
API, systèmes distribués et processus critiques
Contrat API
Versionnement, schéma, validation, authentification, autorisation, idempotency key, correlation ID, codes d'erreur stables, SLA, quotas et politique de retry.
Système distribué
Messages perdus, dupliqués, retardés ou réordonnés ; horloges différentes ; dépendances indisponibles ; état partiellement propagé. On conçoit pour l'ambiguïté.
outboxdedupretry bornédead-letterreconciliation
Cybersécurité
Authentification forte, mTLS, signature, chiffrement, tokenisation, HSM, moindre privilège, segmentation, rotation de secrets, anti-rejeu, détection de fraude et protection des données sensibles.
Traçabilité
Logs techniques + journal métier + ledger. Les logs ne remplacent pas l'écriture comptable. Les données sensibles doivent être masquées, avec intégrité, rétention et accès contrôlé.
Machine à états robuste
Ce qu'il faut dire sur l'idempotence
Pont avec ton expérience
| Ton vécu | Traduction paiements | Preuve à raconter |
|---|---|---|
| API commune véhicule | Contrats inter-systèmes, compatibilité, versionnement, erreurs | Comment tu as aligné producteurs, consommateurs et critères d'acceptation. |
| Architecture distribuée / ECU | Timeouts, états partiels, ordre des messages, reprise | Un défaut difficile reproduit grâce aux traces et à une chronologie. |
| Validation pilote | Tests end-to-end, non-régression, critères de go/no-go | Comment tu as transformé un risque terrain en scénario de test. |
| Projet critique multi-acteurs | Incident, escalade, RACI, communication | Une décision sous contrainte avec responsabilités explicites. |
Trois séquences à maîtriser
| Messages | Demande d'autorisation, réponse avec décision et code ; clearing et settlement suivent plus tard. |
| Données | Montant, devise, token/PAN protégé, marchand, terminal, contexte d'authentification, horodatage, identifiants. |
| Contrôles | Validité carte, solde/limite, vélocité, fraude, statut marchand, authentification, anti-rejeu. |
| Erreurs | Timeout, doublon, réponse tardive, capture différente, indisponibilité réseau. |
| KPI | Taux d'autorisation, p95/p99 latence, disponibilité, taux de timeout, fraude, faux positifs. |
| Responsabilité | Émetteur décide l'autorisation ; acquéreur sert le marchand ; commerçant conserve la preuve de vente. |
| Incident | Si le taux de refus explose, segmenter par émetteur, BIN, pays, terminal, version, règle fraude et code réseau. Vérifier une régression avant d'assouplir le risque. |
| KPI | Approval rate ajusté au mix, soft vs hard decline, faux positif, conversion après retry légitime, taux de support. |
| Responsabilité | La banque émettrice porte la décision de refus ; le commerçant gère l'expérience et ne doit pas promettre que les fonds sont débités. |
| Données | Identité, bénéficiaire, résultat VOP, device, IP, géolocalisation approximative, ancienneté relation, historique, montant, fréquence et signaux de compromission. |
| Contrôles | SCA, VOP, sanctions, AML, fraude comportementale, limites, nouveau bénéficiaire, changement de device, politique de step-up. |
| Incident | Créer un cas fraude, préserver les traces, bloquer si base légale et règle interne, contacter le client, lancer recall si déjà parti, notifier et déclarer selon obligations. |
| KPI | Fraude évitée, faux positifs, abandon, temps de décision, recall recovery rate, pertes nettes, taux de VOP mismatch. |
| Responsabilité | Le PSP du payeur doit exécuter les contrôles prévus et informer correctement ; la cellule fraude décide selon politique ; le bénéficiaire/PSP bénéficiaire intervient dans une récupération éventuelle. |
Gestion d'incident et fraude
Runbook en 8 mouvements
- Détecter et qualifier l'impact.
- Geler les changements et nommer l'incident commander.
- Contenir sans détruire les preuves.
- Décider du mode dégradé ou de l'arrêt.
- Communiquer aux parties selon cadence.
- Rétablir et surveiller.
- Réconcilier tous les flux ambigus.
- RCA, actions et preuve de clôture.
Les questions de war room
Combien de clients et quel montant ? Les opérations sont-elles seulement retardées ou économiquement dupliquées ? Le ledger est-il fiable ? Peut-on arrêter l'entrée sans bloquer la sortie ? Quels identifiants permettent de reconstruire le périmètre ? Qui doit être informé ?
Mini-simulateur
Situation : depuis 7 minutes, l'acquéreur reçoit des timeouts, tandis que certains émetteurs montrent des autorisations approuvées. Le taux de retry marchand augmente.
KPI et SLI utiles
Transformer les connaissances en réponses d'entretien
Quelle différence entre autorisation et settlement ?
Clique pour retourner
L'autorisation est une décision temps réel et peut réserver un montant. Le clearing présente ensuite l'opération et calcule les obligations. Le settlement transfère finalement les fonds entre institutions. Je surveille donc des états distincts et je réconcilie les écarts.
Comment éviter un double paiement lors d'un timeout ?
Je conserve l'intention économique via une idempotency key, persiste le résultat, réutilise la même clé au retry et interroge le statut. Si le protocole le prévoit, je déclenche une reversal. Les cas ambigus vont en réconciliation, jamais en retry aveugle.
Que fait ISO 20022 ?
Il fournit un modèle sémantique et des définitions de messages financiers. SEPA utilise des profils de ces messages dans ses rulebooks. L'infrastructure de clearing/settlement les transporte et les traite.
Pourquoi le SCT Inst change la fraude ?
Le paiement doit être décidé et exécuté en secondes, 24/7. Les contrôles principaux doivent donc être temps réel. Après settlement, la récupération n'est pas garantie ; VOP, scoring, SCA, limites et step-up avant envoi deviennent essentiels.
Pitch de 90 secondes adapté à ton profil
Grille pour répondre à un cas
1. Cadrer
Canal, instrument, montant, pays, temps réel, acteurs, finalité.
2. Dérouler
Messages, contrôles, états, écritures, erreurs, responsabilité.
3. Piloter
KPI, monitoring, incident, réconciliation, amélioration.