ATM Nearby™

Lorsque la DSP2 est entrée en vigueur en 2018, les prestataires de services d'information sur les comptes (AISP) ont acquis une existence juridique officielle. Les banques ont eu l'obligation d'ouvrir leurs API à des tiers agréés, et les consommateurs ont obtenu le droit légal d'autoriser ces tiers à accéder aux données de leurs comptes de paiement. Sept ans plus tard, des centaines d'AISP sont enregistrés à travers l'Europe, et ce modèle s'est étendu au Royaume-Uni, au Brésil, à l'Australie et à certaines régions du Moyen-Orient.

Ouvrez n'importe quelle application bancaire, faites défiler le flux de vos transactions récentes, et vous constaterez que le problème est toujours le même : une ligne de lettres majuscules cryptiques là où devrait figurer le nom du commerçant. Cette ligne correspond au libellé de paiement, cette courte chaîne de caractères qui accompagne la transaction et s'affiche dans l'application à côté du montant. C'est l'élément déterminant qui permet au client de reconnaître son achat, d'identifier le bénéficiaire et de vérifier la légitimité du débit. Les banques ont rarement la main sur ces données et, sous leur forme brute, elles sont rarement exploitables telles quelles.

Lorsqu'un client règle ses achats par carte, le système émetteur de la banque reçoit un ensemble de données de transaction provenant du réseau bancaire, à la structure rigide mais étonnamment succincte. Les champs sont normalisés, les valeurs sont limitées, et la plupart des informations qu'un utilisateur final s'attend à voir dans son application — noms de commerçants clairs, logos, catégories identifiables, adresses précises des boutiques — sont tout simplement absentes du message. Tout, de la lisibilité des relevés bancaires à l'octroi de crédit, repose sur le traitement ultérieur de ces données brutes. C'est précisément ce fossé entre les informations reçues et les besoins réels du client qui constitue le défi majeur en matière de données dans la banque de détail.