Looker pour une fintech : TPV, chargebacks, churn, encours

Une revue hebdomadaire d'activité dans une fintech de paiement et de crédit repose sur une vingtaine d'indicateurs, et presque tous cachent un piège : volume tenté ou réglé, dispute rattachée au mois de la transaction ou d'ouverture, encours additionné comme un flux, client compté une fois par version de son profil. La méthode qui tient consiste à écrire chaque règle une fois dans dbt, à la tester, et à ne laisser Looker exposer que des sommes et des ratios de totaux. Nous avons publié un dépôt de référence complet, avec son propre générateur de données, pour montrer chaque motif en code.

Réglé, pas tenté : TPV, revenu, take rate

Un paiement par carte passe par l'autorisation, la compensation et le règlement. Une autorisation peut être annulée ou expirer, une tentative refusée n'a déplacé aucun argent, un remboursement le rend. Compter le volume autorisé surestime le volume de paiement du taux d'annulation et fait dériver le take rate avec le délai de règlement.

Statut de la tentative	Compte dans le TPV	Porte du revenu
Réglée (paiement carte ou virement)	Oui	Oui, frais plus interchange
Réglée (rechargement du compte)	Non, elle finance le compte sans payer personne	Oui si des frais existent
Autorisée, pas encore réglée	Pas encore	Pas encore
Refusée	Non	Non
Remboursée	Non, elle passe dans le taux de remboursement	Non, malgré les frais présents dans la source

La dernière ligne explique pourquoi la définition doit vivre à un seul endroit : le flux source conserve les frais sur les lignes remboursées, et le filtre de statut qui rend le revenu juste est écrit une fois dans int_transactions_enriched. Le take rate est le revenu divisé par le TPV, un ratio de deux totaux. La conversion en euros se fait une fois dans dbt, au taux du jour qui compte pour chaque fait : date de transaction pour les paiements, date d'ouverture pour les disputes, date de photo pour les encours. Looker ne multiplie jamais par un taux.

Autorisation et mix de refus

Le taux d'autorisation est le nombre de tentatives de paiement carte non refusées divisé par le nombre total de tentatives, et le taux de refus son complément, découpé par motif. Le mix des motifs est ce qui rend l'indicateur actionnable : une hausse des refus pour fonds insuffisants raconte l'état des clients, une hausse des refus pour fraude suspectée à des heures nocturnes sur de tout petits montants raconte une campagne de test de cartes.

Chargebacks : ratios internes et seuils des réseaux

Visa et Mastercard surveillent les commerçants sur un ratio mensuel de disputes, mais les deux réseaux ne le calculent pas de la même façon, et une fintech qui acquiert ou émet doit connaître les deux.

Programme	Ratio	Seuils
Visa, VAMP (depuis avril 2025, remplace VDMP et VFMP)	Fraudes déclarées (TC40) plus disputes (TC15), divisées par les transactions réglées (TC05), transactions à distance	Acquéreur : 50 points de base « au-dessus du standard », 70 « excessif ». Commerçant excessif : 220 points de base en Europe, Amérique du Nord et Asie-Pacifique, abaissé à 150 le 1er avril 2026 ; minimum 1 500 fraudes et disputes par mois
Visa, énumération	Autorisations énumérées (approuvées et refusées) sur toutes les autorisations	20 % et 300 000 transactions énumérées
Mastercard, ECM	Chargebacks du mois divisés par les transactions du mois précédent	ECM : au moins 100 chargebacks et 1,50 %. HECM : au moins 300 et 3,00 %. Sortie après trois mois consécutifs sous le seuil

Deux leçons pour la couche sémantique. D'abord, un ratio interne ne reproduira jamais exactement celui du réseau, qui compte ses propres codes de transaction ; l'indicateur interne sert à voir la tendance avant la lettre de l'acquéreur. Ensuite, la date de rattachement change tout : le dépôt calcule le taux par mois de transaction, comme les réseaux, sur fct_transactions, et garde fct_chargebacks par mois d'ouverture pour l'équipe qui traite la file. Les totaux concordent, les découpages mensuels non, et le glossaire dit pourquoi. Les disputes arrivant jusqu'à 120 jours après la transaction, les derniers mois sont incomplets par construction, et la tuile le dit.

Le tableau de bord trace une ligne de référence à 0,9 %, l'ancien seuil standard des programmes Visa ; les seuils en vigueur sont ceux du tableau ci-dessus, et la ligne est un paramètre de la tuile, pas une définition.

Clients actifs et churn au grain client-mois

Le churn est l'indicateur que trois équipes calculent de trois façons. Le dépôt le fixe sur une table fct_customer_months : une ligne par client et par mois calendaire, produite par une grille de mois et des fonctions de fenêtre dans int_customer_activity.

Drapeau	Définition
Actif	Au moins une transaction réglée dans le mois
Nouveau	Premier mois actif
Récurrent	Actif dans un mois postérieur au premier
Réactivé	Actif après au moins un mois inactif, sous-ensemble de récurrent
Perdu	Actif le mois précédent, inactif ce mois

Les clients actifs mensuels valent nouveaux plus récurrents, chaque mois, et un test dbt le vérifie. Le taux de churn est le nombre de clients perdus divisé par les clients actifs du mois précédent. Une seconde mesure, les actifs à 30 jours glissants, existe pour la vue « aujourd'hui » et le glossaire précise que les deux ne se comparent pas.

Encours : une photo, pas un flux

L'encours de crédit est un solde. Le dépôt le porte dans fct_loan_snapshots, une ligne par prêt et par fin de mois, avec le capital restant dû, les jours de retard et la tranche d'impayé. La mesure est décrite comme ponctuelle, le tableau de bord la regroupe par mois de photo, et un drapeau is_latest_snapshot donne une valeur unique sûre sans regroupement par date. Le piège inverse est classique : une tuile « encours » qui additionne douze fins de mois dès que quelqu'un retire le mois de la requête.

Les taux d'impayé à 30 et 90 jours sont des ratios de capital, pas de nombre de prêts, et le taux moyen pondéré est la somme des capitaux multipliés par le taux, divisée par l'encours, jamais une moyenne des taux par prêt.

SCD2 : l'historique client et la justesse des cohortes

Un client change de segment, passe une vérification d'identité, ferme un compte. dim_customers garde une ligne par version, avec ses dates de validité. Reste à savoir quelle version chaque fait doit voir.

Le dépôt résout la version dans dbt, par une jointure d'intervalle sur l'horodatage du fait, et pose une clé de version customer_sk sur chaque transaction, mois client et photo de prêt. Le revenu par segment reflète alors le segment du client au moment où l'argent a bougé ; current_segment reste disponible pour l'autre lecture. L'explore des clients filtre sur is_current pour que chacun compte une fois.

L'erreur qui coûte le plus est de joindre la table de versions sur la clé naturelle : chaque transaction est multipliée par le nombre de versions du client, et un COUNT DISTINCT masque le problème sur les comptes en le laissant dans les sommes. Côté cohortes, la table dérivée cohort_retention porte la taille de chaque cohorte sur toutes ses lignes avec FIRST_VALUE, de sorte que le dénominateur ne dépend pas des mois filtrés.

Données personnelles

Noms, e-mail et date de naissance vivent dans dim_customers à côté des attributs métier, et chaque champ porte required_access_grants: [pii_access]. Un raffinement les regroupe sous un libellé « PII », et la tranche d'âge dérivée hérite du grant de la date de naissance. Le filtre de lignes par pays est un mécanisme distinct, piloté par le même attribut utilisateur : un analyste limité à un pays voit les lignes de ce pays et aucune donnée personnelle, un administrateur voit tout.

Le dépôt de référence, pas à pas

Le code est public : looker-semantic-layer-fintech, sous licence MIT.

Les données. Faute de jeu public convenable, un générateur déterministe (data/generate.py, bibliothèque standard uniquement) produit neuf fichiers CSV chargés comme seeds dbt : 5 000 clients en historique SCD2, comptes, cartes, commerçants avec code MCC, 159 000 transactions sur 24 mois, chargebacks, prêts avec photos mensuelles, taux de change. La CI régénère les fichiers et échoue si un CSV a été modifié à la main.

dbt. Staging, deux modèles intermédiaires, quatre faits et trois dimensions, 134 tests dont des invariants métier : un chargeback n'existe que sur un paiement carte réglé, une tentative refusée ne porte aucun revenu. Le glossaire liste 19 métriques métier et 37 composants, M1 à M56, et le linter refuse une mesure dont l'identifiant n'y figure pas.

LookML. Six explores, chacun ancré sur un fait à un grain unique, jointures many_to_one uniquement, un datagroup, une table dérivée de rétention, un access grant et un filtre par pays. Le tableau de bord weekly_business_review a sept tuiles et trois filtres.

Intégration continue. Trois jobs : régénération des seeds, dbt build incrémental sur les pull requests, et un linter qui, en plus des règles habituelles, résout chaque référence de champ des vues, des explores et du tableau de bord avant la fusion.

FAQ

Pourquoi notre taux de chargeback interne diffère-t-il de celui de l'acquéreur ?

Parce que le réseau compte ses propres codes de transaction, applique ses exclusions, et Mastercard divise par les transactions du mois précédent. L'indicateur interne doit être défini une fois, expliqué, et suivi comme un signal avancé ; la réconciliation exacte se fait sur le rapport de l'acquéreur.

Faut-il un modèle par devise ?

Non. Une conversion unique dans dbt, au taux daté pertinent pour chaque fait, avec une colonne en euros à côté du montant natif. Les montants natifs restent visibles avec un avertissement de ne pas les additionner.

Le dépôt fonctionne-t-il sur nos propres données ?

La couche staging est la seule à connaître le générateur. Remplacez les neuf modèles stg_ par vos tables et gardez les noms de colonnes en sortie : les couches intermédiaire, marts et LookML restent identiques.

Et ensuite

Si votre revue hebdomadaire affiche un TPV en finance et un autre au produit, commencez par la table des statuts ci-dessus : une ligne par statut, une décision par ligne. Le dépôt montre ensuite comment cette table devient un booléen, une mesure et une tuile.

Voir l'offre Couche sémantique BigQuery, dbt, Looker, et pour aller plus loin : Couche sémantique : pourquoi vos chiffres ne concordent pas et Checklist d'audit LookML.

Sources

• Visa, Visa Acquirer Monitoring Program Overview, fact sheet 2025, formule du ratio, seuils acquéreur et commerçant, ratio d'énumération, abaissement à 150 points de base au 1er avril 2026.
• Chargeback Gurus, Visa Acquirer Monitoring Program (VAMP), calendrier du programme et remplacement de VDMP et VFMP.
• Mastercard via J.P. Morgan, Excessive Chargeback Program, Merchant Program Guide, calcul du ratio, seuils ECM et HECM, conditions de sortie.
• Checkout.com, What is the Mastercard Excessive Chargeback Program, formule en points de base.