Comment un Eligibility Engine détermine-t-il les conditions et limites ?

L'Eligibility Engine vérifie les conditions d'utilisation de l'EWA au moment où le salarié formule une demande. Il ne crée pas de salaire acquis : il reçoit le résultat du calcul, puis applique l'état du dossier, la politique de l'entreprise, les limites d'utilisation et les contrôles afin de déterminer si la demande peut continuer et dans quel périmètre.

À quelle question l'Eligibility Engine répond-il ?

Deux questions sont facilement confondues dans l'EWA :

1. Quel montant le salarié a-t-il acquis grâce au travail approuvé ?
2. À cet instant, est-il autorisé à utiliser le service et dans quelle limite peut-il recevoir ?

La première relève de l'Earned Wage Engine. La seconde relève de l'Eligibility Engine.

Séparer les deux couches évite de confondre la valeur déjà créée par le travail et l'autorisation d'utiliser une fonction financière.

Un salarié peut avoir des journées approuvées sans avoir terminé les formalités de son dossier. À l'inverse, son dossier peut être complet sans qu'il dispose encore d'un salaire acquis suffisant.

Six groupes de conditions généralement vérifiés

Un bon Eligibility Engine organise les conditions en groupes ayant un sens opérationnel clair.

Groupe de contrôle	Question à résoudre	Source des données
Statut du salarié	Le dossier est-il actif et dans le périmètre applicable ?	HRM/ERP
Travail et salaire acquis	Un salaire acquis a-t-il été généré ?	Earned Wage Engine
Politique de l'entreprise	La politique est-elle activée pour ce lieu de travail ?	Policy/configuration
Identité et compte	Le profil de réception a-t-il été vérifié ?	Identity/account
Limites d'utilisation	La demande actuelle se situe-t-elle dans le périmètre autorisé ?	Policy + transaction ledger
État du système	Une condition impose-t-elle l'arrêt ou la mise en attente ?	Transaction/monitoring

Chaque condition doit avoir une source de données et un propriétaire clairement définis.

Si une règle repose sur des données sans source de référence, il devient très difficile d'expliquer pourquoi un salarié a été refusé ou limité.

Une limite découle de la politique, pas du salaire acquis

Dans l'EWA, la « limite » ne doit pas être comprise comme une somme indépendante accordée à l'avance au salarié.

L'Earned Wage Engine détermine d'abord le salaire déjà acquis.

L'Eligibility Engine peut ensuite appliquer des règles pour réduire le périmètre d'utilisation autorisé, mais il ne doit pas créer une valeur supérieure au salaire acquis éligible.

La relation peut être représentée ainsi :

Valeur utilisable ≤ Salaire acquis éligible déjà généré

Pour le service d'accès au salaire acquis de Nhan Kiet, le calcul de base est :

Montant disponible = (journées approuvées × taux journalier) − montant déjà perçu pendant la période − réserve prévue par l'entreprise.

Les autres conditions d'utilisation sont ensuite évaluées.

Pourquoi revérifier au moment de la demande ?

Un statut « éligible » affiché dans l'application peut déjà être obsolète.

Entre l'ouverture de l'écran et la confirmation, il peut arriver que :

• une journée soit modifiée ;
• une autre transaction aboutisse ;
• le statut du salarié change ;
• le compte ne soit plus valide ;
• une nouvelle version de politique entre en vigueur ;
• une transaction précédente soit encore en attente.

Le serveur doit donc réévaluer les conditions lors de la création de la demande.

L'interface doit seulement afficher les informations ; la décision finale doit reposer sur les données les plus récentes du serveur.

Quelle différence entre Eligibility Engine et Earned Wage Engine ?

Couche	Question principale	Données clés
Earned Wage Engine	Quel salaire acquis a déjà été généré ?	Travail, taux, montant perçu, réserve
Eligibility Engine	Cette personne peut-elle utiliser le service et dans quel périmètre ?	Dossier, politique, limites, compte
Payment Orchestration	Comment une demande valide sera-t-elle traitée ?	ID de transaction, état, banque

La séparation des trois couches attribue à chacune une responsabilité claire.

Si le travail change, l'Earned Wage Engine recalcule. Si la politique change, l'Eligibility Engine réévalue. Si le réseau bancaire dépasse le délai, Payment Orchestration gère l'état de la transaction.

Les politiques doivent avoir une version et une date d'effet

Une erreur de conception courante consiste à ne conserver que la « politique actuelle ».

Quelques mois plus tard, l'entreprise peut ne plus pouvoir expliquer pourquoi une ancienne transaction était autorisée alors qu'une opération comparable à une autre date ne l'était pas.

Chaque ensemble de règles doit comporter :

• un code de version ;
• une date et une heure d'effet ;
• un périmètre ;
• un créateur ;
• un approbateur ;
• le motif de la modification ;
• un état actif/inactif.

Lors de l'évaluation d'une demande, le système doit conserver la trace de la version de politique utilisée.

Quand l'Eligibility Engine doit-il s'arrêter ?

Lorsque des données importantes ne sont pas assez fiables, le moteur ne doit pas ouvrir automatiquement l'accès.

Par exemple :

• l'état d'une transaction précédente est incertain ;
• les données de travail sources sont en conflit ;
• le compte destinataire n'est pas valide ;
• le dossier n'est plus actif ;
• la version applicable de la politique est indéterminable ;
• un système source ne répond pas de manière vérifiable.

Dans ces cas, la conception sûre consiste à mettre la demande en attente de vérification, plutôt que de supposer que tout est correct.

C'est le même principe de fermeture sécurisée utilisé dans les systèmes de traitement de fonds.

Les codes de motif sont aussi importants que le résultat

L'Eligibility Engine ne doit pas renvoyer uniquement :

• true ;
• false ;
• un chiffre.

Il doit fournir des motifs structurés, par exemple :

• aucune journée approuvée ;
• dossier non vérifié ;
• fonction non activée par le client ;
• demande hors du périmètre autorisé ;
• une transaction est en attente ;
• nouvelle vérification du compte nécessaire.

Les codes de motif permettent :

• à l'interface d'expliquer le résultat ;
• à l'assistance de rechercher le cas ;
• aux opérations de classer les erreurs ;
• de produire des statistiques ;
• d'auditer les décisions.

Les détails techniques sensibles n'ont pas à être révélés, mais l'utilisateur doit savoir quelle action entreprendre.

Comment l'entreprise doit-elle gouverner l'Eligibility Engine ?

L'Eligibility Engine doit être considéré comme une politique exécutable, et non comme un simple morceau de code.

Chaque règle importante doit avoir :

• un propriétaire métier ;
• une source de données ;
• une date d'effet ;
• une raison d'exister ;
• un périmètre ;
• un traitement des exceptions ;
• un historique des changements.

Les équipes produit et paie doivent s'accorder sur la frontière entre le salaire acquis et la part autorisée à l'utilisation.

Les opérations doivent savoir pourquoi une demande est mise en attente.

L'assistance doit disposer de codes suffisamment clairs pour expliquer le résultat sans accéder aux configurations techniques sensibles.

KPI à suivre

Il est possible de suivre :

• le taux d'éligibilité ;
• le taux de mise en attente faute de travail approuvé ;
• le taux de mise en attente lié au dossier ou au compte ;
• les demandes bloquées par une transaction en attente ;
• le nombre de changements de politique ;
• les réclamations sur l'éligibilité ;
• le taux de décisions accompagnées d'un code complet ;
• les exceptions traitées manuellement.

Il ne faut pas optimiser les KPI dans le sens « autoriser le plus de transactions possible ». L'objectif est d'être conforme aux conditions, explicable et cohérent.

Conclusion

L'Eligibility Engine aide l'EWA à distinguer le salaire acquis déjà généré du droit d'utiliser le service à un moment précis. Un bon moteur réévalue les conditions lors de la demande, utilise des politiques versionnées, renvoie des codes clairs et s'arrête lorsque les données importantes sont incertaines. L'entreprise peut ainsi faire évoluer sa politique tout en préservant l'intégrité de la paie et la capacité d'explication aux salariés.

Auteur : Do Huy Le — Tổng Giám Đốc, Nhan Kiet Manpower Supply Co., Ltd.

Conseil en accès au salaire acquis pour les entreprises : Hotline 0937.022.655 · E-mail info@nhankiet.vn · Accès au salaire acquis pour les entreprises