Votre template de données pour le traitement des paiements
Votre template de données pour le traitement des paiements
Ceci est notre modèle de données générique de Process Mining pour Traitement des paiements. Utilisez nos modèles spécifiques au système pour des directives plus précises.
Sélectionnez un système spécifique- Définitions complètes des champs pour le suivi des transactions
- Cartographie universelle des activités pour les cycles de vie des paiements
- Structures de données évolutives compatibles avec tout système financier
Attributs de traitement des paiements
| Nom | Description | ||
|---|---|---|---|
| Dernière mise à jour des données LastDataUpdate | L'horodatage indiquant quand l'enregistrement a été extrait ou actualisé pour la dernière fois. | ||
| Description Cet attribut suit la fraîcheur des données utilisées dans l'analyse. Il reflète le moment où les données ont été chargées dans l'outil de Process Mining ou la dernière modification de l'enregistrement dans la base de données source. Disposer de ces informations est vital pour la gouvernance des données et la confiance. Cela permet aux analystes de savoir s'ils consultent des données en temps réel ou un instantané de la veille. C'est particulièrement important pour le suivi des paiements actifs qui pourraient être bloqués dans un état en attente. Bien qu'il ne soit pas utilisé directement pour les calculs de workflow, il sert de champ de contrôle de métadonnées pour garantir que les dashboards affichent l'état le plus actuel des opérations de paiement. Pourquoi c'est important Garantit la fraîcheur des données et aide à déboguer les problèmes de latence du pipeline de données. Où obtenir Généré lors de l'extraction des données ou du processus ETL. Exemples 2023-10-27T12:00:00Z2023-10-27 23:59:592023-10-28 06:00:0027/10/20232023-11-01 01:00:00.000 | |||
| ID de transaction de paiement PaymentTransactionId | L'identifiant unique représentant l'instruction de paiement ou le cas de transaction spécifique. | ||
| Description Cet attribut sert de clé centrale pour relier toutes les activités au sein d'un même cycle de vie de paiement. Il permet aux outils de Process Mining de reconstituer le parcours de bout en bout d'un paiement, de son initiation à son règlement final ou à son échec. En analyse, cet identifiant est utilisé pour regrouper des events distincts en une seule instance de case. Il permet la visualisation du workflow et est essentiel pour calculer les temps de cycle par transaction. Sans ID unique, il est impossible de distinguer des milliers de paiements simultanés circulant dans le système. Ce champ reste généralement constant tout au long de la durée de vie du paiement. Cependant, dans des scénarios complexes impliquant plusieurs systèmes, il peut s'agir d'une clé composite ou être mappé à partir d'un numéro de référence unique de bout en bout. Pourquoi c'est important C'est le Case ID fondamental requis pour créer un modèle de processus et suivre des paiements spécifiques. Où obtenir Généralement trouvé dans l'en-tête de transaction, la table des instructions de paiement ou le journal du grand livre principal (main ledger log). Exemples TRX-8859201PAY-2023-X9910029384f47ac10b-58cc-4372-a567-0e02b2c3d479INSTR-5542 | |||
| Nom de l'activité ActivityName | L'étape, le changement de statut ou l'événement spécifique survenu dans le cycle de vie du paiement. | ||
| Description Cet attribut décrit l'action effectuée ou le changement d'état qu'un paiement a subi à un moment précis. Parmi les exemples, citons la création de la demande, les vérifications de validation, les étapes d'autorisation ou le règlement final. Le Process Mining s'appuie sur cet attribut pour définir les nœuds de la carte de processus. En analysant la séquence de ces activités, les analystes peuvent identifier les variantes courantes, les boucles où les paiements sont retravaillés et les bottlenecks où les paiements stagnent pendant de longues périodes. La normalisation de ces noms entre les différents systèmes sources est souvent nécessaire pour créer une vue cohérente du processus. Par exemple, un système peut appeler une étape 'Auth' tandis qu'un autre l'appelle 'Authorization', et ces termes doivent être alignés lors de la transformation des données. Pourquoi c'est important Il définit les nœuds de la cartographie et permet d'analyser le flux et les variantes du processus. Où obtenir Situé dans les journaux d'audit, les historiques de statuts ou les tables de suivi d'événements. Exemples Paiement crééPaiement autoriséPaiement échouéRèglement confirméErreur de validation | |||
| Système source SourceSystem | Le nom de l'application ou du système d'origine des données d'événement. | ||
| Description Cet attribut identifie l'origine technique de l'enregistrement. Dans les processus de paiement de bout en bout, les données circulent souvent à travers plusieurs systèmes, tels qu'une passerelle front-end, un moteur de détection de fraude et un grand livre (ledger) back-end. L'analyse des données par système permet aux utilisateurs d'isoler les problèmes techniques. Par exemple, si des retards sont constamment observés dans le moteur de fraude mais pas dans le grand livre, l'analyse des causes profondes peut être ciblée efficacement. Cela aide également à valider l'intégrité des données lors de la fusion de plusieurs sources de données. Ce champ est généralement ajouté pendant le processus d'extraction et de transformation s'il n'existe pas explicitement dans les données source. Il sert de marqueur de lignage à des fins d'audit et de débogage. Pourquoi c'est important Crucial pour l'analyse multi-systèmes et l'identification du composant à l'origine des retards ou des erreurs. Où obtenir Souvent codé en dur lors du processus ETL ou situé dans les métadonnées système. Exemples PaymentGateway_01CoreBankingSystemFraudEngineSwiftInterfaceERP_SAP | |||
| Timestamp de l'événement EventTimestamp | La date et l'heure précises auxquelles l'activité ou le changement de statut a eu lieu. | ||
| Description Cet attribut enregistre le moment exact où un event a eu lieu au sein du système de paiement. Il sert d'ancrage chronologique pour le processus, garantissant que les events sont correctement ordonnés au sein du case. Dans l'analyse, ce timestamp est la base de tous les calculs basés sur le temps. Il est utilisé pour déterminer la durée entre les activités, le temps de cycle total de bout en bout et le respect des accords de niveau de service (SLA). Des timestamps précis sont essentiels pour identifier quand les bottlenecks se produisent. Une haute précision est préférable, surtout pour le trading à haute fréquence ou les systèmes de paiement automatisés où les millisecondes sont importantes. Si seules les dates sont disponibles sans les heures, l'ordonnancement des activités qui se produisent le même jour peut nécessiter une logique de tri secondaire. Pourquoi c'est important Indispensable pour ordonner les événements et calculer tous les KPI de durée, comme le temps de cycle. Où obtenir Situé dans les journaux de transactions, les tables d'historique ou les pistes d'audit système. Exemples 2023-10-15T08:30:00Z2023-10-15 14:45:12.5502023-11-01T09:00:00+00:0015/10/2023 20:30:002023-10-16 10:15:00 | |||
| Code d'erreur ErrorCode | Le code spécifique ou le motif généré lors de l'échec ou du rejet d'un paiement. | ||
| Description Cet attribut capture la raison technique ou métier d'un échec de processus. Il est renseigné lorsqu'un paiement est rejeté, échoue à la validation ou rencontre une erreur de transmission. L'analyse des codes d'erreur est la méthode principale pour réduire le 'Taux d'échec de paiement' et le 'Taux de retravail'. Le regroupement des codes communs aide à identifier des problèmes systémiques, comme des erreurs de master data ou des soucis de connectivité avec les chambres de compensation. Dans un scénario idéal (happy path), ce champ est nul. Sa présence indique généralement une déviation du flux optimal et déclenche des sous-processus de gestion des exceptions. Pourquoi c'est important L'attribut principal pour l'analyse des causes racines (Root Cause Analysis) des échecs et du retravail. Où obtenir Situé dans les journaux d'erreurs, les messages de rejet ou les données de réponse. Exemples FONDS_INSUFFISANTSCOMPTE_INVALIDESUSPICION_FRAUDETIMEOUTRÉF_DOUBLON | |||
| Code de devise CurrencyCode | Le code ISO à 3 lettres désignant la devise du paiement. | ||
| Description Cet attribut spécifie l'unité monétaire du montant du paiement, telle que USD, EUR ou GBP. Il est essentiel pour une information financière précise et pour déclencher des workflows transfrontaliers spécifiques. L'analyse nécessite souvent un filtrage par devise pour comprendre la performance régionale ou les délais de traitement des opérations de change. Différentes devises peuvent avoir des heures limites, des cycles de règlement et des exigences réglementaires différents, ce qui influence directement le workflow. Sans cet attribut, le champ 'Montant du paiement' est ambigu. Ce champ permet la conversion de montants disparates en une seule devise de rapport pour les dashboards globaux. Pourquoi c'est important Nécessaire pour normaliser les valeurs financières et identifier les variantes de processus transfrontaliers. Où obtenir Situé à côté du montant du paiement dans les tables de transactions. Exemples USDEURGBPJPYCAD | |||
| Date d'échéance du paiement PaymentDueDate | La date à laquelle le paiement doit être réglé au plus tard. | ||
| Description Cet attribut représente la date limite cible pour le paiement. Il permet au système de mesurer le 'Taux de Paiement dans les Délais' et de déterminer si les accords de niveau de service (SLA) ont été respectés. La comparaison du timestamp d'achèvement réel avec cette date d'échéance fournit une métrique claire de la performance du processus. Les paiements effectués après cette date sont considérés comme en retard, ce qui peut entraîner des pénalités ou nuire aux relations commerciales. Ce champ est particulièrement pertinent pour les processus de comptes fournisseurs ou les contrats de prestation de services garantis où le calendrier est une obligation contractuelle. Pourquoi c'est important Requis pour calculer le respect des SLA et les taux de paiements ponctuels. Où obtenir Situé dans l'en-tête de la facture ou l'instruction de demande de paiement. Exemples 2023-10-302023-11-012023-10-152023-12-312024-01-01 | |||
| Méthode de paiement PaymentMethod | L'instrument ou le mécanisme spécifique utilisé pour exécuter le paiement. | ||
| Description Cet attribut classe le paiement selon son type d'exécution, tel que virement bancaire, ACH, carte de crédit ou paiement instantané. Chaque méthode suit généralement un chemin de processus distinct avec des attentes de délais et des coûts différents. En segmentant les données à l'aide de cet attribut, les analystes peuvent comparer la performance des différentes filières de paiement. Par exemple, les virements bancaires peuvent nécessiter davantage d'étapes d'approbation manuelles par rapport aux traitements ACH automatisés. Comprendre la répartition des méthodes de paiement aide à la planification des capacités et à l'identification des changements de comportement des clients, comme une migration des chèques traditionnels vers les paiements numériques instantanés. Pourquoi c'est important Indispensable pour distinguer les variantes de processus (ex : Instantané vs Virement) qui ont des SLA différents. Où obtenir Situé dans les détails de l'instruction de paiement. Exemples VirementACHCarte de créditVirement SEPAPaiement en temps réel | |||
| Montant du paiement PaymentAmount | La valeur monétaire associée à la transaction de paiement. | ||
| Description Cet attribut représente la valeur financière transférée. C'est la principale métrique numérique pour évaluer l'impact des inefficacités de processus. Par exemple, un retard dans un paiement d'un million de dollars est souvent plus critique qu'un retard dans un paiement de dix dollars. En analyse, ce champ est utilisé pour agréger les volumes, calculer les besoins totaux en liquidités et segmenter les paiements par tranches de valeur. Les paiements de grande valeur suivent souvent des workflows d'approbation différents de ceux de faible valeur, et cet attribut aide à différencier ces chemins. Il est essentiel d'associer cet attribut au code de devise pour garantir des comparaisons équitables. L'agrégation des montants sans conversion ou séparation de devises peut conduire à des rapports financiers trompeurs. Pourquoi c'est important Permet l'analyse de l'impact financier et la segmentation des transactions selon leur valeur. Où obtenir Situé dans les détails de la transaction ou les tables d'écritures financières. Exemples 150.0010000,5025,995000000,01 | |||
| Utilisateur de traitement ProcessingUser | L'identifiant de l'utilisateur ou de l'agent système responsable de l'activité. | ||
| Description Cet attribut identifie qui ou quoi a exécuté une étape spécifique du processus de paiement. Il peut faire référence à un utilisateur humain effectuant un examen manuel, ou à un compte système exécutant une tâche automatisée. Ces données sont vitales pour analyser l'utilisation des ressources et les bottlenecks. Elles aident à distinguer entre le traitement automatisé (Straight-Through Processing) et les interventions manuelles. Des taux élevés d'implication manuelle de l'utilisateur sont souvent corrélés à des coûts plus élevés et des délais de cycle plus lents. Pour la conformité, ce champ aide à l'analyse de la séparation des tâches, garantissant que la personne qui a créé un paiement n'est pas la même que celle qui l'a approuvé. Pourquoi c'est important Permet d'analyser les taux d'automatisation (STP) et la productivité des ressources. Où obtenir Situé dans les journaux d'audit ou les colonnes de métadonnées de la table de transactions. Exemples SystemAgent_01jdoeAPPROVER_GROUP_AAutoReconcilerAPI_User | |||
| Canal de traitement ProcessingChannel | L'interface ou le canal par lequel le paiement a été initié. | ||
| Description Cet attribut indique le point d'entrée de l'instruction de paiement, tel qu'une application mobile, un portail web, une API ou un téléversement de fichier (File Upload). Il fournit un aperçu du comportement des clients et de l'utilisation des canaux. L'analyse de la performance des processus par canal peut mettre en évidence des disparités techniques. Par exemple, les paiements initiés via API peuvent être traités instantanément, tandis que les téléversements de fichiers peuvent attendre les fenêtres de traitement par lots. Cela aide à comprendre l'expérience utilisateur sur différentes plateformes. Il est également utile pour analyser le passage des canaux hérités (comme la saisie manuelle ou le fax) aux canaux numériques, soutenant ainsi les initiatives de transformation numérique. Pourquoi c'est important Aide à analyser les tendances de volume et les écarts de performance selon les points d'entrée (ex : Mobile vs Web). Où obtenir Situé dans l'en-tête de la transaction ou les métadonnées de session. Exemples Mobile AppPortail webFichier H2HAPITerminal de paiement (TPE) | |||
| Nom du bénéficiaire BeneficiaryName | Le nom de l'entité ou de la personne recevant le paiement. | ||
| Description Cet attribut identifie le bénéficiaire. Dans un contexte B2B, il s'agit du fournisseur ; dans un contexte P2P, c'est le destinataire individuel. Il fournit le contexte de qui est payé. L'analyse des paiements par bénéficiaire peut révéler des schémas tels que des paiements fréquents à des entités à haut risque ou un risque de concentration avec des fournisseurs spécifiques. Elle est également utile pour l'analyse des fraudes, en identifiant si plusieurs petits paiements sont acheminés vers un seul bénéficiaire inattendu. Des problèmes de qualité des données sont courants ici, avec des variations d'orthographe (par exemple, 'Inc.' vs 'Incorporated'). Le nettoyage de ces données est souvent nécessaire pour une agrégation précise. Pourquoi c'est important Utile pour l'analyse des fournisseurs, la détection de la fraude et le profilage des risques. Où obtenir Situé dans la section des détails du bénéficiaire de l'instruction de paiement. Exemples Acme CorpGlobal Services LtdJohn SmithAzure Cloud ServicesAutorité fiscale | |||
| Score de Risque RiskScore | Un score numérique indiquant la probabilité de fraude ou de risque de conformité. | ||
| Description Cet attribut est une valeur générée par les moteurs de détection de fraude ou les modèles de risque. Un score plus élevé indique généralement une probabilité plus forte que la transaction soit frauduleuse ou à haut risque. Dans l'analyse de processus, ce score aide à expliquer pourquoi certains paiements passent par des boucles de révision prolongées. Les paiements avec des scores de risque élevés déclenchent souvent des activités d'intervention manuelle, augmentant le temps de cycle. Corréler les scores de risque avec les résultats finaux (approuvé vs rejeté) aide à ajuster l'efficacité des règles de risque. Tous les systèmes ne génèrent pas un score numérique ; certains peuvent seulement fournir un indicateur de statut. Cependant, pour les passerelles de paiement modernes, c'est une métrique standard pour la prise de décision. Pourquoi c'est important Explique les déviations de processus comme les révisions manuelles et les blocages pour contrôle antifraude. Où obtenir Résultat du système de détection de fraude ou du moteur de risque. Exemples 08512.5994 | |||
Activités de traitement des paiements
| Activité | Description | ||
|---|---|---|---|
| Instruction de paiement envoyée | La transmission du fichier ou message de paiement finalisé au réseau externe ou à la chambre de compensation. Cela marque le passage du système interne vers l'extérieur. | ||
| Pourquoi c'est important Il s'agit d'une étape clé qui sépare le temps de traitement interne du temps de règlement externe. Où obtenir Consigné lors de la génération de fichiers, de l'envoi d'appels API ou du passage au statut Transmis. Capture Identifier le timestamp de l'appel API sortant ou du transfert de fichier. Type d'événement explicit | |||
| Paiement approuvé | Le jalon interne où un utilisateur autorisé ou une règle système donne le feu vert. Distinct de l'autorisation financière externe, il représente la validation organisationnelle. | ||
| Pourquoi c'est important Souvent une source majeure de goulots d'étranglement dus aux workflows manuels et à la latence humaine. Où obtenir Enregistré dans les journaux d'approbation du workflow ou lorsque l'indicateur d'approbation passe à 'vrai'. Capture Enregistrer le timestamp lors de la validation de l'approbation finale en base de données. Type d'événement explicit | |||
| Paiement autorisé | La confirmation financière que les fonds sont réservés ou disponibles. Cela correspond souvent à une interaction avec le système bancaire central ou l'émetteur de carte. | ||
| Pourquoi c'est important La confirmation de l'autorisation est un point de contrôle clé avant le mouvement réel des fonds. Où obtenir Situé dans les journaux de réponse de la passerelle ou les tables d'autorisation du système bancaire central. Capture Extraire le timestamp du code de réponse d'autorisation positif. Type d'événement explicit | |||
| Paiement créé | La création initiale de l'enregistrement de transaction dans le système. Cet événement capture le timestamp de la première journalisation, qu'elle soit manuelle ou via API. | ||
| Pourquoi c'est important Établit le point de départ du cycle de paiement de bout en bout et sert de base à l'analyse des volumes. Où obtenir Généralement trouvé dans le timestamp de création de la table de transaction principale ou dans une entrée de journal d'audit dédiée pour les nouveaux enregistrements. Capture Extraire le timestamp le plus ancien associé à l'ID de transaction de paiement. Type d'événement explicit | |||
| Paiement échoué | Un statut terminal indiquant que le paiement n'a pas pu être effectué en raison de problèmes techniques ou financiers irrécupérables. Cela représente la fin définitive de l'instance du processus. | ||
| Pourquoi c'est important Un indicateur clé de fiabilité ; l'analyse des tendances ici aide à réduire l'abandon des transactions. Où obtenir Extrait des codes de statut d'échec final ou des journaux d'erreurs fatales. Capture Identifier les transactions entrant dans un état d'échec terminal. Type d'événement explicit | |||
| Paiement réglé | La finalisation réussie du mouvement financier, les fonds étant crédités au bénéficiaire. C'est l'état final de succès d'une transaction. | ||
| Pourquoi c'est important Utilisé pour calculer le temps de cycle complet et constitue le critère de succès principal du processus. Où obtenir Généralement indiqué par un statut de règlement spécifique, un rapport de confirmation ou une écriture au grand livre. Capture Extraire la date et l'heure auxquelles la confirmation de règlement est traitée. Type d'événement explicit | |||
| Erreur de paiement identifiée | Indique que le système ou un validateur externe a signalé un problème (fonds insuffisants, données invalides, etc.). Cet événement marque le début d'une boucle de gestion des exceptions. | ||
| Pourquoi c'est important Essentiel pour calculer les taux de retravail et identifier les problèmes de qualité lors de la saisie des données en amont. Où obtenir extrait des journaux d'erreurs, des tables d'exceptions ou des codes de statut indiquant un échec ou une suspension. Capture Filtrer les codes d'erreur ou les mises à jour de statut qui signalent une transaction à corriger. Type d'événement explicit | |||
| Erreur de paiement résolue | Indique la correction d'un problème identifié, permettant au paiement de revenir dans le flux normal. Cela implique généralement une intervention manuelle ou un mécanisme de relance automatique. | ||
| Pourquoi c'est important Essentiel pour mesurer le temps et les efforts consacrés à la résolution des exceptions de paiement. Où obtenir Déduit lorsqu'une transaction passe d'un état d'erreur à un état de traitement ou de préparation. Capture Détecter les transitions de statut passant des codes d'erreur aux statuts de traitement valides. Type d'événement inferred | |||
| Paiement annulé | L'arrêt délibéré d'un paiement par un utilisateur ou administrateur avant son règlement. Cela annule de fait la transaction. | ||
| Pourquoi c'est important Distinguer les annulations des échecs est important pour différencier le comportement des utilisateurs des erreurs système. Où obtenir Consigné explicitement lors de l'exécution d'une commande d'annulation ou d'un passage au statut Annulé. Capture Capturer le timestamp de la commande d'annulation. Type d'événement explicit | |||
| Paiement Confirmé | La réception d'un accusé de réception technique du réseau externe. Cela confirme que l'instruction est reçue, valide et intégrée au pipeline externe. | ||
| Pourquoi c'est important Vérifie que le transfert au réseau a été réussi et que la transaction est en attente de règlement. Où obtenir capturés à partir des messages d'accusé de réception (ACK) entrants ou des webhooks du fournisseur. Capture Enregistrer l'heure de réception de l'accusé de réception du système externe. Type d'événement explicit | |||
| Paiement rapproché | Le processus comptable où l'enregistrement du système de paiement est confronté aux relevés bancaires ou grands livres externes. Cela garantit que les comptes reflètent la réalité. | ||
| Pourquoi c'est important Indique la clôture administrative de la transaction et garantit l'intégrité financière. Où obtenir Situé dans les modules de rapprochement ou déduit lorsqu'un ID de correspondance est attribué à la transaction. Capture Lier la transaction au timestamp de la table de rapprochement. Type d'événement calculated | |||
| Paiement rejeté | L'événement par lequel un approvateur interne ou un contrôleur externe refuse explicitement la demande de paiement. Cela interrompt le flux et peut générer une notification. | ||
| Pourquoi c'est important Important pour analyser les motifs de rejet et réduire le bruit dans le pipeline de paiement. Où obtenir Consigné explicitement dans l'historique du workflow ou déduit d'une mise à jour de statut final comme Rejeté ou Refusé. Capture Capturer l'action spécifique par laquelle un utilisateur ou un système génère un événement de rejet. Type d'événement explicit | |||
| Paiement remboursé | Survient lorsqu'un paiement réglé est annulé, renvoyant les fonds au payeur. Cette activité a généralement lieu une fois le processus principal officiellement terminé. | ||
| Pourquoi c'est important Les taux de remboursement sont un indicateur de qualité clé pour le service ou produit commercial sous-jacent. Où obtenir Extrait d'une transaction de remboursement liée ou d'un changement de statut indiquant une inversion. Capture Identifier les événements de remboursement liés à l'ID de paiement d'origine. Type d'événement explicit | |||
| Paiement validé | La fin des contrôles automatisés sur l'instruction de paiement (syntaxe, validité du compte, conformité). Cette étape garantit que les données sont saines avant l'approbation ou l'exécution. | ||
| Pourquoi c'est important Une durée élevée ici peut indiquer la lenteur des services de validation externes ou des règles de conformité complexes. Où obtenir Généralement enregistré lorsque le statut passe de Brouillon à Validé ou déduit d'un journal de succès de validation. Capture Identifier les changements de statut indiquant une validation réussie ou des entrées spécifiques d'un moteur de conformité. Type d'événement inferred | |||
Guides d'extraction
Les méthodes d'extraction varient selon le système. Pour des instructions détaillées,