Un responsable conformité à Singapore écrit une phrase : repérer les clients qui fractionnent de gros dépôts en espèces en montants juste inférieurs au seuil de revue propre à la banque. Aucun langage de requête. Aucun ticket adressé aux équipes techniques.
Sur quelle fenêtre les dépôts doivent-ils compter comme une même série ? Choisissez, ou saisissez la vôtre.
Ou partez d’un modèle : la bibliothèque montre ce que chacun a produit sur votre propre trafic.
Vyra reçoit chaque événement en direct, évalue tout le workflow, puis s’arrête avant le nœud d’action. Aucun dossier ouvert, aucune notification envoyée, aucun client affecté. Le chemin d’évaluation est identique à celui de la production : ce que vous lisez est ce que la production aurait fait.
Across the first nine days, 14,208 transactions, this version would have raised 96 would-be alerts about 0.7% of volume. The number will move as more traffic arrives. Do not act on it yet.
Deux mesures distinctes, tenues à l’écart à dessein. Ne les fondez pas en un seul chiffre dans vos rapports.
Une correspondance retient la transaction, ouvre un dossier sur l’entité et joint tout ce qui a été lu : les conditions, les valeurs, le résultat de filtrage. Elena V. décide, et la décision arrive au format attendu par your FIU.
Fiable pour les principales institutions financières et les leaders fintech de la région EMEA
Le même agent, à trois moments de sa vie. Construit dans l’espace de travail que vos analystes utilisent déjà, éprouvé sur votre propre historique, et redevable de chaque dossier qu’il ouvre.
Ajoutez une condition sur les dépôts effectués dans trois agences ou plus sur la même fenêtre. Sur vos quatre-vingt-dix derniers jours, elle sépare les commerçants légitimes du schéma que vous décrivez.
Chaque version conserve le trafic sur lequel elle a été testée. Quand un régulateur demande pourquoi un agent s’est comporté ainsi en mars, vous ouvrez la version qui était en production en mars.
Sept dépôts dans trois agences, aucun au-dessus de $900k, $4.87m au total face à un chiffre d’affaires déclaré de $1.4m par mois. Aucune facture correspondante au dossier. Je recommande une EDD et un projet de STR.
Le même endpoint transporte chaque événement à chaque étape. Ombre, déploiement progressif et production ne diffèrent que par une valeur d’en-tête : vous branchez une fois et changez d’avis autant que nécessaire. Le retour arrière automatique reste armé en production, mais ce qui a été fait avant reste fait.
POST /v1/agents/{agent}/evaluateX-Vyra-Mode: shadow"event_id": "TXN-8841027","entity": { "account_id": "ACC-4471" },"transaction": { "amount": 28000, "currency": "USD", "direction": "outbound" }Un modèle qui a tourné ici porte les chiffres qu’il a produits sur votre trafic réglé, et la bibliothèque est classée selon la qualité du backtest sur vos données. Ceux qui n’y ont jamais tourné le disent, plutôt que d’emprunter les chiffres d’un autre.
Ou décrivez-en un qui n’est pas dans la bibliothèque. C’est à cela que sert Vyra.
Chaque agent qui se déclenche ouvre un dossier sur l’entité concernée, celle-là même que l’onboarding a constituée. Les transactions, le profil déclaré du client, les alertes antérieures et le raisonnement de Vyra y sont déjà joints quand votre analyste l’ouvre.
Vyra enquête. Votre workflow décide.
| Dossier | Sévérité | SLA |
|---|---|---|
| Fractionnement · dépôts sous le seuilCASE-8842 · Amara C. | Élevée | 4h left |
| Entrées et sorties immédiates · 11 comptesCASE-8836 · Lucas Moreau | Élevée | 19h |
| Volume transfrontalier au-dessus du profilCASE-8829 · Meridian Logistics | Moyenne | 2d |
| Compte dormant, flux soudainCASE-8817 · Sofia Rossi | Faible | 3d |
Une activité de paiement atteint ses payeurs à travers des marchands : ce qu’elle sait d’eux est donc mince un e-mail, une raison sociale, un compte. L’appareil qui a envoyé le paiement est la partie que personne ne peut saisir à la main.
Les signaux de fraude arrivent avec le paiement, lus par le SDK au moment du paiement ou transmis dans le payload. Ils se résolvent en un profil de payeur unique, qui s’affine chaque fois que ce payeur revient.
Vous pouvez donc savoir que cet appareil a déjà été à l’origine d’impayés, chez des marchands sans lien entre eux, pour un payeur dont vous n’avez jamais pu vérifier le nom.
L’e-mail et la raison sociale servent de liens entre sessions, jamais de faits.
Le bénéficiaire est filtré comme une contrepartie à part entière. Celui-ci a reçu de neuf sous-marchands ce mois-ci, sans lien entre eux sur le papier.
Sur le payeur, et sur le bénéficiaire lorsque l’argent repart. Lesquels s’exécutent, et ce que fait une correspondance : c’est votre workflow qui le dit.
Loaded alongside, read as one more condition — at sub-merchant onboarding and on every payment after.
Un schéma ne paraît anormal que par comparaison. Pour une banque, c’est le profil déclaré du client. Pour une activité de paiement, c’est celui du marchand : le corridor, le panier moyen et l’historique du marchand que vous avez intégré. Dans les deux cas il vient de l’onboarding, l’appareil qui a ouvert la session vient des signaux de fraude, et le dossier qu’un agent ouvre repose sur le même enregistrement.
C’est le même type de logique, écrit autrement. Vous décrivez le schéma en une phrase ; Vyra assemble les conditions, l’action et l’alerte depuis votre bibliothèque de variables, et vous lisez chaque ligne avant exécution. Ce qui change, c’est le délai entre le repérage d’une typologie et sa mise en production, et le fait que le raisonnement soit consigné.
Non. Le backtest est une porte : rien ne peut être déployé avant qu’il ne passe sur votre trafic réglé. Le mode ombre est ensuite optionnel : il évalue les événements réels et supprime chaque action qu’il aurait prise, aussi longtemps que vous voulez cette preuve. Passer en production est un choix explicite dont la conséquence est écrite à côté, et l’historique conserve qui a choisi quoi et pourquoi.
Les alertes sont notées, non empilées, et un client sur une fenêtre déclenche une alerte plutôt qu’une par transaction. Avant d’activer un agent, vous voyez ce qu’il a produit sur votre trafic réglé. La précision confirmée par les décisions d’analystes est rapportée séparément de la précision estimée sur des alertes que personne n’a examinées : les deux ne sont jamais fondues en un seul chiffre.
Oui. Les conditions s’assemblent à partir de variables nommées nombres de dépôts, montants cumulés, ratios face à un profil déclaré avec les opérateurs et fenêtres que vous définissez dans le panneau. Vyra propose ; vous modifiez, ajoutez et supprimez à la main à tout moment.
L’intégration se fait par API et prend généralement des jours, non des trimestres, le schéma de transactions étant mappé sur les variables que lisent vos agents. Les règles existantes peuvent être importées et testées à côté des nouvelles.
Pour chaque alerte : la version de l’agent déclenchée, les conditions évaluées, les valeurs lues, le dossier ouvert, qui l’a traité, ce qui a été décidé et quand. La version en production à ce moment est conservée : une décision de mars s’explique avec les termes de mars.
Un seul dossier d’entité. Un schéma est noté face à un profil vérifié à l’onboarding celui du client dans une banque, celui du marchand dans une activité de paiement et l’appareil qui a ouvert la session vient des signaux de fraude. Les contreparties que personne n’a intégrées sont filtrées plutôt que profilées, sur le même dossier et dans la même file de cas.
Aussi longtemps que vous le souhaitez. Aucune date de fin fixée : il tourne jusqu’à ce que vous l’arrêtiez, l’estimation se resserre chaque jour de trafic, et l’évaluation en ombre est facturée à l’usage pendant ce temps. Les premiers chiffres sont marqués provisoires et indicatifs, car sur quelques jours de données ils ne sont rien de plus.
Oui, par filtrage plutôt que par profilage. Un message de paiement porte un nom de contrepartie, un compte, une banque, un corridor, un montant et un BIN de carte, et cela est filtré contre les sanctions, les listes de surveillance, les PPE et médias défavorables, le risque corridor et banque bénéficiaire, l’exposition aux PSAN et la géographie de l’émetteur. Le paiement est ensuite comparé au marchand que vous avez intégré, à ce que cette contrepartie a déjà fait sur votre trafic, et à tout ce qui circule chez ce marchand sur la même fenêtre.
Oui. Les STR et les états sont rédigés depuis le dossier au format attendu par votre régulateur, et les agents peuvent être cadrés par marché : un seuil dans un pays ne vous suit pas dans un autre.
Une alerte de surveillance ne devient pas un silo de plus. Elle reste sur le même dossier d’entité utilisé pour l’onboarding, l’enquête et la déclaration.
Apportez-nous quatre-vingt-dix jours de transactions. Nous construirons un agent à partir d’une phrase devant vous, le rejouerons sur votre propre historique et vous montrerons ce qu’il aurait détecté.
Youverify détient les certifications SOC 2 Type II, ISO 27001, ISO 27018 et ISO 42001, et est enregistré auprès des autorités de protection des données au Nigeria, au Kenya, en Afrique du Sud, en Côte d’Ivoire et au Royaume-Uni.
