WO2023075581A1 - Procede de verification instantanee des cheques et des lettres de change normalisees - Google Patents

Procede de verification instantanee des cheques et des lettres de change normalisees Download PDF

Info

Publication number
WO2023075581A1
WO2023075581A1 PCT/MA2022/000009 MA2022000009W WO2023075581A1 WO 2023075581 A1 WO2023075581 A1 WO 2023075581A1 MA 2022000009 W MA2022000009 W MA 2022000009W WO 2023075581 A1 WO2023075581 A1 WO 2023075581A1
Authority
WO
WIPO (PCT)
Prior art keywords
check
exchange
bank
payment
standardized
Prior art date
Application number
PCT/MA2022/000009
Other languages
English (en)
Inventor
Abdelali BOUKACHABINE
Original Assignee
Boukachabine Abdelali
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Boukachabine Abdelali filed Critical Boukachabine Abdelali
Publication of WO2023075581A1 publication Critical patent/WO2023075581A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/042—Payment circuits characterized in that the payment protocol involves at least one cheque
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/108—Remote banking, e.g. home banking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3223—Realising banking transactions through M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G06Q20/4037—Remote solvency checks

Definitions

  • the present invention relates to a management method making it possible to fight against unpaid Checks and unpaid Standardized Bills of Exchange by allowing a merchant receiving payment by one of these two payment instruments to have real-time visibility on its client's ability to honor its commitment.
  • the invention makes it possible to manage the interaction between a trader receiving payment by Check or by a Standardized Bill of Exchange, who wishes to check the solvency of his customer, and the bank of the drawee using a center processor connected to a plurality of banks through secure communication channels.
  • the check is the second most used payment instrument by value with 998.2 billion dirhams for 27.7 million transactions, i.e. 28% of the volumes exchanged and 9.5% of the number of exchanges made.
  • the freeness of the check and its systematic delivery at the opening of the bank account can be identified as being among the main reasons which have made this instrument one of the most used means of payment byixies in previous years. Standardized Bills of Exchange, for their part, represented in 2020, 1.6% of the number of exchanges carried out and 7.9% of the volumes exchanged.
  • WO 2009/088272 A1 which aims to allow a bank customer to consult his bank account, by sending a PIN1 code via a wired or wireless telephone device, a computer, an ATM, or a check reader by through the Internet, satellite and telephone networks to ensure that the balance of his account covers the amount of the check issued, and order the blocking of the amount in question before giving the check to a third party; bearing his signature and fingerprint.
  • the third party can in turn verify this solvency by using a PIN2 code made available to the drawee.
  • This invention is based on the sending of a PIN code by both the client and the third party, unlike the method described here which does not require any PIN code exchange either with the client or with the third party.
  • the process described here allows a trader receiving a payment by Check or Standardized Bill of Exchange to have real-time visibility on the ability of his customer to honor his commitment. Furthermore, this invention, unlike the method described here, does not make it possible to provide a degree of assurance through the probability of the occurrence of a Check or Standardized Bill of Exchange payment incident.
  • the subject of the invention is a management method making it possible to combat unpaid Checks and unpaid Standardized Bills of Exchange by allowing a trader receiving payment by one of these two payment instruments to have real-time visibility on the ability of its client to honor its commitment.
  • the invention makes it possible to manage the interaction between a trader receiving payment by Check or by a Standardized Bill of Exchange, who wishes to check the solvency of his customer, and the bank of the drawee using a center processor connected to a plurality of banks through secure communication channels.
  • the method also offers merchants, during the commercial transaction, additional assurance for decision-making with a view to accepting or not accepting a means of payment from their customers, through the generation of a percentage of probability of occurrence of a payment incident for a Check or Standardized Bill of Exchange calculated on the basis of a predictive rating model.
  • FIG-1 is an illustration of a Standardized Check or Bill of Exchange with a CMC7 track used in this process.
  • FIG-2 is a synthetic representation of all the technical means of communication used by the merchant to instantly check the Check presented or the Standardized Bill of Exchange presented by the customer to the latter's bank.
  • FIG-3 presents in detail the information exchanged between the server of the processing center (sending mobile device) and the server of the drawee's bank (destination mobile device).
  • FIG-4 Illustrates a flow chart that describes the operation of the method shown in FIG-2.
  • FIG-5 illustrates the percentages which reflect the relative contribution of each type of data, grouped into categories, in the calculation of the predictive rating relating to the probability of occurrence of a payment incident for a Check or a Standard Bill of Exchange.
  • FIG-6 refers to the points of each of the categories and which can be aggregated to arrive at an overall predictive rating. Indeed, each of the five categories can have one or more temporal attributes which are used to generate points which can be, in turn, aggregated and weighted across all categories to result in an overall predictive score.
  • the invention relates to a management method making it possible to fight against unpaid Checks and unpaid Standardized Bills of Exchange by allowing a merchant beneficiary of a payment by Check or by a Standardized Bill of Exchange to have real-time visibility on its client's ability to honor its commitment.
  • a Standard Check or Bill of Exchange 7 is shown with a track CMC7 (7-segment Coded Magnetic Character Code) 4 printed on the face of the Check or Standard Bill of Exchange 7.
  • CMC7 track 4 is located in the very bottom space of Check 7.
  • CMC7 track 4 may be located elsewhere on Standard Bill of Exchange 7, e.g. at the bottom left of the Standard Bill of Exchange.
  • FIG-1 illustrates a standard Personal Check
  • the present invention works equally well with Company Checks.
  • the CMC7 4 track contains information concerning the account number and the Check number or the Standardized Bill of Exchange 7.
  • the CMC7 4 track is a seven-digit digital coding system made with a magnetic still.
  • a mobile phone 9 is used to read the CMC7 track 4 on the Check or Standardized Bill of Exchange 7.
  • a check reader or scanner 11 connected to a computer can also be used by a merchant to read the CMC7 track 4.
  • FIG-4 the illustrated flowchart describes the operation of the method shown in FIG-2.
  • An image recognition software routine on the merchant's mobile phone 9 determines the account number on the Check or the Standardized Bill of Exchange 7 from the CMC7 track 4.
  • the image recognition software subroutine which allows the extraction of the CMC7 track 4 begins once the image, taken by the mobile telephone 9 or by the check reader or the scanner 11 connected to a computer of a merchant, a Check or a Standardized Bill of Exchange 7, is recorded on the server of the processing center 3. Indeed, the image recognition software subroutine is triggered by the detection of the box where is the CMC7 track 4, choosing the coordinates of the upper left corner and the lower right corner. On each of the 7 Checks of the banks in the square, the CMC7 track 4 is inside this box, with a white background and black numbers and symbols.
  • the cropped image is transformed into a matrix of 0 and 1 according to the gray scale. Indeed, for each box, the process makes it possible to calculate the lightest pixel and the darkest pixel, in order to cancel the contrast effect, which can be different from one check to another depending on the banks. .
  • a decision value has been defined by the letter A and which corresponds to half the value between the darkest pixel and the light pixel. If a pixel is less than A, the pixel would become 0, if it is greater than 1.
  • MatrixOI a matrix of 0 and 1 , which will be called MatrixOI , where 1 represents black and 0 represents white. This way it is much easier to manage the numbers.
  • the method thus uses two functions which make it possible to detect the digits.
  • the first function removes zero-filled left columns from a given OIMatrix.
  • the second function removes zero-filled bottom rows from a given OIMatrix.
  • the first function is used with an OI Matrix to ensure that the first column is the beginning of the first digit and to determine the width of each digit. Then the first function is used again with a new MatrixOI with the columns containing the first digit and only that digit of Matrix 01 "Mother". The second function is subsequently applied by the process to this same matrix, which makes it possible to ensure that the figure is always aligned with the lower left corner. And since the height of a figure is already determined, the pattern removes rows that won't be used.
  • This step is closed by the extraction of the first MatrixOI which corresponds to the first matrix of figures and surrounded by Matrix 01 "Mother".
  • the method repeats this process as many times as the number of digits.
  • each bank check will give as many vectors as digits on track CMC7 4.
  • FIG-3 illustrates an alternative embodiment of the system shown in FIG-2.
  • data center server 3 is connected directly to bank 10 using data link 5.
  • Data link 5 allows two-way transfers of data between data center server 3 and bank 10.
  • Data link 5 may be a conventional mobile telephone line.
  • a software routine on the processing center server 3 uses a lookup table to determine how to contact bank 10.
  • the lookup table contains the bank codes and corresponding contact details for each bank.
  • the contact information includes the necessary data and in particular the security token to connect and communicate with the bank 10.
  • Real time is defined as the time a customer waits at the point of sale. This waiting time may vary depending on the type of business transaction offered by the merchant.
  • a customer presents a Check or Standardized Bill of Exchange 7 to the merchant.
  • the trader takes, with his mobile phone 9 or with the check reader or the scanner 11 connected to a computer, an image of the Check or of the Standardized Bill of Exchange 7.
  • the image of the Check or of the Standardized Bill of Exchange 7 is then recorded on the server of the processing center 3.
  • An image recognition software subroutine on the server of the processing center 3 determines the account number and the number of the Check or the Standardized Bill of Exchange 7 from the information contained in track CMC7 4 as well as the amount.
  • the server of the processing center 3 contacts the bank 10 via a data link 5 allowing access to a data service provided by the bank 10 in complete safety.
  • Processing center 3 determines which bank to call based on the bank code that is part of the account number extracted from the CMC7 track 4.
  • the processing center 3 server then calls the appropriate bank 10, allowing the center to processing 3 to transmit the account number and the number of the Check or the Standardized Bill of Exchange 7 to the appropriate bank 10 as well as the amount.
  • Bank 10 verifies the status of the account and sends the responses back to the server of the processing center 3 via data link 5.
  • the responses transmitted by the server of the bank 10 of the drawee (sending mobile device) to the server of the processing center 3 (recipient mobile device) are as follows:
  • the responses transmitted by the server of the bank 10 of the drawee to the server of the processing center 3 are translated according to a precise combination towards a traffic light 6 presenting the three colors: Red, Orange, Green and are displayed on the mobile telephone 9 or on the merchant's computer to which the check reader or scanner 11 is connected, with a well-detailed description for each of the colors.
  • the traffic light 6 will be accompanied by a percentage P of probability of occurrence of a payment incident for a Check or a Standardized Bill of Exchange 7 generated by the predictive scoring model described in the present invention.
  • the predictive model can be trained using a historical data set of payment incidents Checks and Standardized Bills of Exchange 7.
  • the data is collected which relates to values for each of the plurality of variables used by the predictive scoring model to generate a percentage probability of occurrence of a payment incident for a Check or a Standard Bill of Exchange 7.
  • a predictive rating relating to a percentage P of the probability of occurrence of a payment incident for a Check or Standardized Bill of Exchange 7 is generally calculated from several different data. This data can be grouped into five categories:
  • FIG-5 is an illustration of the percentages that reflect the relative contribution CR of each category in the calculation of the predictive rating relating to the probability of occurrence of a payment incident for a Check or a Standardized Bill of Exchange 7.
  • the points from each of the categories can be aggregated to come up with an overall predictive scoring.
  • each of the five categories can have one or more time attributes which are used to generate points which can be, in turn, aggregated and weighted across all categories to result in a score. global predictive.
  • the number of points can be based on the number of payment incidents recorded.
  • the number of points can be based on the existence of a balance greater than the amount of the Check or the Standardized Bill of Exchange 7.
  • the weighting of the existence of a balance P2 (bank balance + possibly a cash facility) greater than the amount of the Check or the Standardized Bill of Exchange 7 is calculated by dividing the number of points of the attribute of a Check or a Standardized Bill of Exchange 7 by the total number points.
  • the number of points can be based on whether the amount of the Check or the Standardized Bill of Exchange 7 belongs to one of the six installments of the amounts of payment incidents declared to the CIP.
  • the weighting of the belonging of the amount P3 of the Check or the Standardized Bill of Exchange 7 to one of the six tranches of the amounts of the payment incidents declared to the CIP is calculated by dividing the number of points of the attribute of a Check or Standardized Bill of Exchange 7 by the total number of points.
  • the attribute of the belonging of the amount of a Check to one of the six tranches of the amounts of payment incidents declared to the CIP is between 10,000 DH and 50,000 DH
  • the number of points may be based on the average of the sector evaluations published by the COFACE sector risk barometer over the past five years.
  • the number of points can be based on the monthly average of payment incident reports processed by the CIP over the past five years.
  • the percentage P of probability of occurrence of a payment incident for a Check or a Standardized Bill of Exchange 7 generated by the predictive scoring model is calculated as follows:
  • the bank 10 proceeds to check the status of the account and returns the responses to the server of the processing center 3 via the data link 5.
  • the responses transmitted by the server of the bank 10 of the drawee to the server of the processing center 3 and the information extracted from the Check highlight the attributes below :
  • the percentage P of probability of occurrence of a Check payment incident generated by the predictive scoring model is as follows:
  • the merchant can then decide whether or not to accept the Check or the Standardized Bill of Exchange 7. If the merchant decides to accept the Check or Standardized Bill of Exchange 7, the sale is concluded. If the merchant decides not to accept the Check or Standardized Bill of Exchange 7, the sale may be canceled or the customer may offer another method of payment. In the event of loss or theft of the Check or the Standardized Bill of Exchange 7, the merchant may be asked to contact the bank 10 to inform him that this lost or stolen means of payment has been presented to this merchant. In one embodiment of this invention, the availability of funds in the customer's bank account is not affected by the verification process. However, the invention can also be put into practice with a view to blocking the amount of the Check or Standardized Bill of Exchange 7 on the customer's bank account at the time of the sale.
  • the bank account information extracted from the CMC7 track 4 of the customer's Check or Standardized Bill of Exchange 7 and that received from the customer's bank 10 can optionally be saved and used with a program executed for a remittance to the collection of checks and bills of exchange Normalized 7 to merchant's bank for payment and clearing. Using previously recorded customer bank account information reduces the time it takes for the merchant to process Checks or Standardized Bills of Exchange 7 at the end of the day. Other transaction details such as item or service purchased, quantity and price can be recorded for future reporting.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Finance (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention a pour objet un procédé de gestion permettant de lutter contre les Chèques impayés et les Lettres de Change Normalisées impayées en permettant à un commerçant bénéficiaire d'un paiement par l'un de ces deux instruments de paiement de disposer en temps réel de la visibilité sur la capacité de son client à honorer son engagement. L'invention permet de gérer l'interaction entre un commerçant bénéficiaire d'un paiement par un Chèque ou par une Lettre de Change Normalisée, qui souhaite vérifier la solvabilité de son client, et la banque du tiré à l'aide d'un centre de traitement relié à une pluralité de banques par l'intermédiaire de voies de communication sûres. Le procédé offre également aux commerçants, lors de la transaction commerciale, une assurance supplémentaire pour la prise de décision en vue de l'acceptation ou non d'un moyen de paiement de leurs clients, et ce à travers la génération d'un pourcentage de probabilité d'occurrence d'un incident de paiement d'un Chèque ou d'une Lettre de Change Normalisée calculé sur la base d'un modèle de notation prédictif.

Description

PROCEDE DE VERIFICATION INSTANTANEE DES CHEQUES ET DES LETTRES DE CHANGE NORMALISEES
DOMAINE DE L'INVENTION AUQUEL SE RAPPORTE L'INVENTION
La présente invention concerne un procédé de gestion permettant de lutter contre les Chèques impayés et les Lettres de Change Normalisées impayées en permettant à un commerçant bénéficiaire d’un paiement par l’un de ces deux instruments de paiement de disposer en temps réel de la visibilité sur la capacité de son client à honorer son engagement. L’invention permet de gérer l'interaction entre un commerçant bénéficiaire d’un paiement par un Chèque ou par une Lettre de Change Normalisée, qui souhaite vérifier la solvabilité de son client, et la banque du tiré à l'aide d'un centre de traitement relié à une pluralité de banques par l'intermédiaire de voies de communication sûres.
ART ANTERIEUR
Au terme de l’année 2020, le chèque est le deuxième instrument de paiement support le plus utilisé en valeur avec 998,2 milliards de dirhams pour 27,7 millions d’opérations, soit 28% des volumes échangés et 9,5% du nombre des échanges réalisés. En effet, la gratuité du chèque et sa livraison systématique à l’ouverture du compte bancaire peuvent être identifiées comme étant parmi les des raisons principales qui ont fait de cet instrument un des moyens de paiement les plus utilisés par les Marocains durant les années précédentes. Les Lettres de Change Normalisées, quant à elles, ont représenté en 2020, 1 ,6% du nombre des échanges réalisés et 7,9% des volumes échangés.
Par ailleurs et selon les données publiées par la Bank Al Maghrib, le nombre total de rejets de Chèques en 2020, tous motifs confondus, s’est élevé à 713 777 opérations, correspondant à un taux de rejet global de 3,17% (contre 2,72% en 2019). 60% de ces rejets étaient liés à l’insuffisance de provision lors de la présentation au règlement.
Ces incidents de paiement par Chèque notamment les non régularisés ont un impact significatif sur l’économie d’un pays. En effet au Maroc, l’encours des incidents de paiement non encore régularisés, enregistré auprès de la centrale des incidents de paiement de Bank Al Maghrib s’est établi à 107,8 milliards de dirhams à fin 2020.
Parallèlement, la proportion des Lettres de Change Normalisées rejetées, qui s’est établie à 18,05% en 2020 demeure inquiétante, d’autant plus que près de 90% des rejets correspondent à des rejets pour absence ou insuffisance de provision. Pour pallier à ces niveaux de rejets préoccupants et rétablir une relative crédibilité de ce type d’instrument de paiement, Bank Al-Maghrib a appelé à la mise en place de mesures dissuasives, à même de prévenir contre les incidents de paiement des Lettres de Change Normalisées, à leur échéance. Des propositions d’amendements au Code de Commerce ont été présentées dans ce sens.
D’autre part, l’augmentation des incidents de paiement a fait perdre la confiance des usagers dans ces deux moyens de paiement. En effet, cela a considérablement réduit leur acceptation auprès des commerçants qui, face à ce risque, préfèrent être payés en espèce ou par un autre moyen de paiement plus sécurisé.
Bien qu’il y ait eu divers procédés impliquant un ou plusieurs des différents éléments utilisés dans la présente invention, aucun à ce jour ne combine ces éléments de la manière unique que le procédé, décrit ici, fait pour fournir une visibilité instantanée aux commerçants qui acceptent les Chèques ou les Lettres de Change Normalisées comme moyens de paiement.
Parmi ces procédés, on cite le procédé :
- US 1999 / 5925865 A qui concerne un système construit autour d’un appareil qui permet la vérification des instruments de paiement tels que les chèques et plus particulièrement à un système d'accès et de vérification automatique de la validité de l'instrument de paiement sur la base des informations contenues dans un code-barres imprimé sur la face de l'instrument. Ce système qui fournit également la possibilité d’imprimer les informations contenues dans le code- barres de l’instrument de paiement sur le ticket de vente, contrairement au procédé décrit ici, ne permet pas de fournir un degré d’assurance à travers une probabilité de l’occurrence d’un incident de paiement Chèque ou Lettre de Change Normalisée.
- WO 2009 / 088272 A1 qui vise à permettre à un client d’une banque de consulter son compte bancaire, en envoyant un code PIN1 via un appareil téléphonique avec ou sans fil, un ordinateur, un guichet automatique, ou un lecteur de chèques par l’entremise des réseaux internet, satellite et téléphonique pour s’assurer que le solde de son compte couvre le montant du chèque émis, et ordonner le blocage du montant en question avant de remettre le chèque à une tierce personne ; comportant sa signature et son empreinte digitale. La tierce personne peut à son tour vérifier cette solvabilité en utilisant un code PIN2 mis en route à la disposition du tiré. Cette invention est basée sur l’envoi d’un code PIN à la fois par le client et la tierce personne, contrairement au procédé décrit ici qui ne nécessite aucun échange de code PIN ni avec le client et ni avec la tierce personne. Aussi, le procédé décrit ici permet à un commerçant bénéficiaire d’un paiement par Chèque ou une Lettre de Change Normalisée de disposer en temps réel de la visibilité sur la capacité de son client à honorer son engagement. Par ailleurs, cette invention, contrairement au procédé décrit ici, ne permet pas de fournir un degré d’assurance à travers une probabilité de l’occurrence d’un incident de paiement Chèque ou Lettre de Change Normalisée. BREVE DESCRIPTION DE L'INVENTION
L’invention a pour objet un procédé de gestion permettant de lutter contre les Chèques impayés et les Lettres de Change Normalisées impayées en permettant à un commerçant bénéficiaire d’un paiement par l’un de ces deux instruments de paiement de disposer en temps réel de la visibilité sur la capacité de son client à honorer son engagement. L’invention permet de gérer l'interaction entre un commerçant bénéficiaire d’un paiement par un Chèque ou par une Lettre de Change Normalisée, qui souhaite vérifier la solvabilité de son client, et la banque du tiré à l'aide d'un centre de traitement relié à une pluralité de banques par l'intermédiaire de voies de communication sûres. Le procédé offre également aux commerçants, lors de la transaction commerciale, une assurance supplémentaire pour la prise de décision en vue de l’acceptation ou non d’un moyen de paiement de leurs clients, et ce à travers la génération d’un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée calculé sur la base d’un modèle de notation prédictif.
BREVE DESCRIPTION DES DESSINS
La présente invention sera mieux comprise à l'étude d'un mode de réalisation particulier pris à titre d'exemple nullement limitatif et illustré par les dessins annexés, sur lesquels :
- FIG-1 : est une illustration d’un Chèque ou une Lettre de Change Normalisée avec une piste CMC7 utilisé dans le présent procédé.
- FIG-2 : est une représentation synthétique de l’ensemble des moyens techniques de communication utilisés par le commerçant pour vérifier instantanément le Chèque présenté ou la Lettre de Change Normalisée présentée par le client auprès de la banque de ce dernier.
- FIG-3 : présente d’une manière détaillée les informations échangées entre le serveur du centre de traitement (dispositif mobile expéditeur) et le serveur de la banque du tiré (dispositif mobile destinataire).
FIG-4 : illustre un organigramme qui décrit le fonctionnement du procédé présenté dans la FIG-2.
- FIG-5 : illustre les pourcentages qui reflètent la contribution relative de chaque type de donnée, regroupée en catégorie, dans le calcul de la notation prédictive relative à la probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée.
- FIG-6 : fait référence aux points de chacune des catégories et qui peuvent être agrégés pour aboutir à une notation prédictive globale. En effet, chacune des cinq catégories peut avoir un ou plusieurs attributs temporels qui sont utilisés pour générer des points qui peuvent être, à leur tour, agrégés et pondérés à travers toutes les catégories pour donner lieu à une notation prédictive globale.
DESCRIPTION DÉTAILLÉE DE L'INVENTION
L’invention concerne un procédé de gestion permettant de lutter contre les Chèques impayés et les Lettres de Change Normalisées impayées en permettant à un commerçant bénéficiaire d’un paiement par Chèque ou par une Lettre de Change Normalisée de disposer en temps réel de la visibilité sur la capacité de son client à honorer son engagement.
En se référant à la FIG-1 , un Chèque ou une Lettre de Change Normalisée 7 est représenté avec une piste CMC7 (sigle de Caractères Magnétiques Codés à 7 bâtonnets) 4 imprimé sur la face du Chèque ou de la Lettre de Change Normalisée 7. La piste CMC7 4 est située dans l'espace tout en bas du Chèque 7. Cependant, la piste CMC7 4 peut être situé ailleurs sur la Lettre de Change Normalisée 7, par ex. en bas à gauche de la Lettre de Change Normalisée.
Bien que non représentée sur la FIG-1 , la présente invention peut également être utilisée avec une Lettre Chèque imprimée par certaines grandes entreprises et dont le numéro de série est réservé et communiqué directement à ces grandes entreprises par leurs banques. Bien que la FIG-1 illustre un Chèque personnel standard, la présente invention fonctionne aussi bien avec les Chèques d'entreprise.
Par conséquent, on comprendra que l'invention décrite n'est pas limitée à l'utilisation de Chèques personnels. Toute référence à un Chèque comprendra les Chèques personnels, les Chèques d’entreprise et les Lettres Chèques imprimées par certaines grandes entreprises ainsi que les Lettres de Change Normalisées.
La piste CMC7 4 contient l’information concernant le numéro de compte et le numéro de Chèque ou la Lettre de Change Normalisée 7. La piste CMC7 4 est un système de codage numérique à sept bâtonnets réalisés avec une encore magnétique.
En se référant à la FIG-2, un téléphone mobile 9 est utilisé pour lire la piste CMC7 4 sur le Chèque ou la Lettre de Change Normalisée 7. Un lecteur de chèque ou un scanner 11 connecté à un ordinateur peut également être utilisé par un commerçant pour lire la piste CMC7 4.
En se référant à la FIG-4, l’organigramme illustré décrit le fonctionnement du procédé présenté dans la FIG-2.
Un sous-programme logiciel de reconnaissance d’image sur le téléphone mobile 9 du commerçant détermine le numéro de compte sur le Chèque ou la Lettre de Change Normalisée 7 à partir de la piste CMC7 4.
Le sous-programme logiciel de reconnaissance d’image qui permet l’extraction de la piste CMC7 4 commence une fois l’image, prise par le téléphone mobile 9 ou par le lecteur de chèque ou le scanner 11 connecté à un ordinateur d’un commerçant, d’un Chèque ou d’une Lettre de Change Normalisée 7, est enregistrée sur le serveur du centre de traitement 3. En effet, le sous-programme logiciel de reconnaissance d’image est déclenché par la détection de l’encadré où se trouve la piste CMC7 4, en choisissant les coordonnées du coin supérieur gauche et du coin inférieur droit. Sur chacun des Chèques 7 des banques de la place, la piste CMC7 4 est à l'intérieur de cet encadré, avec un fond blanc et des chiffres et symboles noirs.
Une fois la détection terminée, l’image recadrée est transformée en une matrice de 0 et 1 selon l'échelle de gris. En effet, pour chaque encadré, le procédé permet de calculer le pixel le plus clair et le pixel le plus sombre, en vue d’annuler l'effet de contraste, qui peut être différent d'un chèque à l’autre selon les banques.
Pour les besoins de ce procédé, une valeur de décision a été défini par la lettre A et qui correspond à la moitié de la valeur entre le pixel le plus sombre et le pixel clair. Si un pixel est inférieur à A, le pixel deviendrait 0, s'il est supérieur à 1 .
Une fois la correspondance terminée, le procédé permet d’avoir une matrice de 0 et 1 , qui sera appelée MatriceOI , où le 1 représente le noir et le 0 représente le blanc. De cette façon, il est beaucoup plus facile de gérer les chiffres.
Les Chèques bancaires émis par les banques marocaines disposent soit de 33 ou de 34 chiffres, et qui constituent un des paramètres traités lors de ce procédé. L’analyse des différentes MatriceOI obtenues, fait ressortir que la hauteur et la largeur des chiffres sont toujours les mêmes du fait que c'est la même police qui est utilisée.
Le procédé utilise ainsi deux fonctions qui permettent de détecter les chiffres.
La première fonction supprime les colonnes de gauche pleines de zéro d'une MatriceOI donnée.
La deuxième fonction supprime les lignes du bas pleines de zéro d'une MatriceOI donnée.
Ainsi, la première fonction est utilisée avec une MatriceOI pour s’assurer que la première colonne est bien le début du premier chiffre et pour déterminer la largeur de chaque chiffre. Ensuite, la première fonction est encore utilisée avec une nouvelle MatriceOI avec les colonnes contenant le premier chiffre et seulement ce chiffre de la Matrice 01 "Mère". La deuxième fonction est appliquée par la suite par le procédé à cette même matrice, ce qui permet de s'assurer que le chiffre est toujours aligné avec le coin inférieur gauche. Et comme la hauteur d'un chiffre est déjà déterminé, le modèle supprime les lignes qui ne seront pas utilisés.
Cette étape est clôturée par l’extraction de la première MatriceOI qui correspond à la première matrice de chiffres et encadré de la Matrice 01 "Mère". Ainsi, le procédé répète ce processus autant de fois que le nombre de chiffres.
Une fois un chiffre extrait, le procédé permet de le convertir en une liste de 0 et 1 . En effet, chaque chèque bancaire donnera autant de vecteurs que de chiffres sur la piste CMC7 4.
Le procédé a pu ainsi terminer l’extraction de plusieurs vecteurs représentant les chiffres, et par la suite il crée des données étiquetées, en vue de la classification de chaque vecteur pour déterminer exactement la piste CMC7 4 à partir de l’image transmise automatiquement sur le serveur du centre de traitement 3. La FIG-3 illustre une variante de réalisation du système représenté sur la FIG-2. Dans ce mode de réalisation, le serveur du centre de traitement 3 est connecté directement à la banque 10 en utilisant une liaison de données 5. La liaison de données 5 permet des transferts bidirectionnels de données entre le serveur du centre de traitement 3 et la banque 10. La liaison de données 5 peut être une ligne téléphonique mobile conventionnelle. Une routine logicielle sur le serveur du centre de traitement 3 utilise une table de recherche pour déterminer comment contacter la banque 10. La table de recherche contient les codes bancaires et les coordonnées correspondantes pour chaque banque. Les informations de contact comprennent les données nécessaires et notamment le token de sécurité pour se connecter et communiquer avec la banque 10.
Les fonctions exécutées par la présente invention se produisent en temps réel. Le temps réel est défini comme le temps d'attente d'un client au point de vente. Ce temps d'attente peut varier en fonction du type de la transaction commerciale offerte par le commerçant.
Dans un premier temps, un client présente un Chèque ou une Lettre de Change Normalisée 7 au commerçant. Le commerçant prend, avec son téléphone portable 9 ou avec le lecteur chèque ou le scanner 11 connecté à un ordinateur, une image du Chèque ou de la Lettre de Change Normalisée 7. L’image du Chèque ou de la Lettre de Change Normalisée 7 est ensuite enregistrée sur le serveur du centre de traitement 3. Un sous-programme logiciel de reconnaissance d’image sur serveur du centre de traitement 3 détermine le numéro de compte et le numéro de Chèque ou de la Lettre de Change Normalisée 7 à partir des informations contenues dans la piste CMC7 4 ainsi que le montant.
Ensuite, le serveur du centre de traitement 3 contacte la banque 10 via une liaison de données 5 permettant d’accéder à un service de données fourni par la banque 10 en toute sécurité. Le centre de traitement 3 détermine quelle banque appeler en fonction du code de la banque qui fait partie du numéro de compte extrait à partir de la piste CMC7 4. Le serveur du centre de traitement 3 appelle alors la banque appropriée 10, permettant au centre de traitement 3 de transmettre le numéro de compte et le numéro du Chèque ou de la Lettre de Change Normalisée 7 à la banque 10 appropriée ainsi que le montant.
Sur la base des requêtes suivantes transmises par le serveur du centre de traitement 3 (dispositif mobile expéditeur) au serveur de la banque 10 du tiré (dispositif mobile destinataire): que le compte bancaire est ouvert ou clôturé ? (41) que le Chèque ou la Lettre de Change Normalisée 7 pris en image fait d’une déclaration de perte ou de vol ? (42) que le Chèque ou la Lettre de Change Normalisée 7 pris en image fait d’une opposition ? (43)
Figure imgf000009_0001
que le tiré a enregistré des incidents de paiement Chèques ou Lettres de Change Normalisées qui ne sont pas encore régularisés ? (44)
Est-ce que le solde du compte bancaire + (éventuellement la facilité de caisse) est supérieur ou égal au montant du Chèque ou de la Lettre de Change Normalisée 7? (45) La banque 10 vérifie l'état du compte et renvoie les réponses au serveur du centre de traitement 3 via la liaison de données 5. Les réponses transmises par le serveur de la banque 10 du tiré (dispositif mobile expéditeur) au serveur du centre de traitement 3 (dispositif mobile destinataire) sont comme suit :
Réponse de la banque 10 : Oui ou Non (51).
Réponse de la banque 10 : Oui ou Non (52).
Réponse de la banque 10 : Oui ou Non (53).
Réponse de la banque 10 : Oui ou Non (54).
Réponse de la banque 10 : Oui ou Non (55).
Les réponses transmises par le serveur de la banque 10 du tiré au serveur du centre de traitement 3 sont traduites selon une combinaison précise vers un trafic light 6 présentant les trois couleurs: Rouge, Orange, Vert et sont affichées sur le téléphone mobile 9 ou sur l’ordinateur du commerçant auquel est connecté le lecteur de chèque ou le scanner 11 , avec une description bien détaillée pour chacune des couleurs.
Le trafic light 6 sera accompagné d’un pourcentage P de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée 7 généré par le modèle de notation prédictif décrit dans la présente invention. Le modèle prédictif peut être entraîné en utilisant un data set historique des incidents de paiement Chèques et Lettres de Change Normalisées 7.
Dans un premier temps, la data est collectée est qui concerne des valeurs pour chacune de la pluralité des variables utilisées par le modèle de notation prédictif pour générer un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée 7.
Une notation prédictive relative à un pourcentage P de la probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée 7, est généralement calculée à partir de plusieurs données différentes. Cette data peut-être regroupée dans cinq catégories :
- L’historique des incidents de paiement des Chèques et des Lettres de Change Normalisées 7.
- Disponibilité ou non des fonds dans le compte bancaire du tiré.
- Montant du Chèque ou de la Lettre de Change Normalisée 7.
- Secteur d’activité du bénéficiaire du Chèque ou de la Lettre de Change Normalisée 7.
- Saisonnalité mensuelle des incidents de paiement des Chèques et des Lettres de Change Normalisées 7.
La FIG-5 est une illustration des pourcentages qui reflètent la contribution relative CR de chaque catégorie dans le calcul de la notation prédictive relative à la probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée 7. Avec certains modèles de notation prédictifs, les points de chacune des catégories peuvent être agrégés pour aboutir à une notation prédictive globale.
En référence au tableau de la FIG-6, chacune des cinq catégories peut avoir un ou plusieurs attributs temporels qui sont utilisés pour générer des points qui peuvent être, à leur tour, agrégés et pondérés à travers toutes les catégories pour donner lieu à une notation prédictive globale.
Pour l’historique des incidents de paiement Chèques ou Lettres de Change Normalisées 7, le nombre de points peut être basé sur le nombre d’incidents de paiement enregistrés. La pondération du nombre d’incidents de paiement enregistrés P1 est calculée en divisant le nombre de point de l’attribut d’un Chèque ou une Lettre de Change Normalisée 7 par le nombre total des points. A titre d’illustration, si l’attribut du nombre d’incidents de paiement enregistré est compris entre 5-10, la pondération P1 est égale à P1 = 18,33%.
Pour la disponibilité des fonds dans le compte bancaire, le nombre de point peut être basé sur l’existence d’un solde supérieur au montant du Chèque ou de la Lettre de Change Normalisée 7. La pondération de l’existence d’un solde P2 (solde bancaire + éventuellement une facilité de caisse) supérieur au montant du Chèque ou de la Lettre de Change Normalisée 7 est calculée en divisant le nombre de point de l’attribut d’un Chèque ou une Lettre de Change Normalisée 7 par le nombre total des points. A titre d’illustration, si l’attribut de l’existence d’un solde supérieur au montant d’un Chèque est égal à solde négatif, la pondération P2 est égale à P2 = 60%.
Pour le montant, le nombre de point peut être basé sur l’appartenance du montant du Chèque ou de la Lettre de Change Normalisée 7 à l’une des six tranches des montants des incidents de paiement déclarés à la CIP. La pondération de l’appartenance du montant P3 du Chèque ou de la Lettre de Change Normalisée 7 à l’une des six tranches des montants des incidents de paiement déclarés à la CIP est calculée en divisant le nombre de point de l’attribut d’un Chèque ou Lettre de Change Normalisée 7 par le nombre total des points. A titre d’illustration, si l’attribut de l’appartenance du montant d’un Chèque à l’une des six tranches des montants des incidents de paiement déclarés à la CIP est compris entre 10 000 DH et 50 000 DH, la pondération P3 est égale à P3 = 33%.
Pour le secteur d’activité du bénéficiaire du Chèque ou de la Lettre de Change Normalisée 7, le nombre de point peut être basé sur la moyenne des évaluations sectorielles publiées par le baromètre des risques sectoriels de la COFACE au cours des cinq dernières années. La pondération de la moyenne des évaluations sectorielles P4 publiées par le baromètre des risques sectoriels de la COFACE au cours des cinq dernières années est calculée en divisant le nombre de point de l’attribut d’un secteur d’activité par le nombre total des points. A titre d’illustration, si l’attribut du secteur d’activité est égal à Distribution, la pondération P4 est égale à P4 = 12,5%.
Pour la saisonnalité des incidents de paiement, le nombre de point peut être basé sur la moyenne mensuelle des déclarations des incidents de paiement traitées par la CIP au cours des cinq dernières années. La pondération de la moyenne mensuelle des déclarations des incidents de paiement P5 traités par la CIP au cours des cinq dernières années est calculée en divisant le nombre de point de l’attribut d’un secteur d’activité par le nombre total des points. A tire d’illustration, si l’attribut de la saisonnalité des incidents de paiement d’un Chèque est égal à Juillet, la pondération P5 est égale à P5 = 9%.
Ainsi, le pourcentage P de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée 7 généré par le modèle de notation prédictif est calculé comme suit :
Figure imgf000012_0001
Par exemple, suite au scan d’un Chèque 7 et sur la base d’une requête transmise par le serveur du centre de traitement 3 au serveur de la banque 10 du tiré, la banque 10 procède à la vérification de l'état du compte et renvoie les réponses au serveur du centre de traitement 3 via la liaison de données 5. Les réponses transmises par le serveur de la banque 10 du tiré au serveur du centre de traitement 3 et les informations extraites du Chèque font ressortir les attributs ci-après :
Figure imgf000012_0002
Le pourcentage P de probabilité d’occurrence d’un incident de paiement du Chèque généré par le modèle de notation prédictif est le suivant :
P = 42% * 18,33% + 33% * 60% + 15% * 33% + 5% * 12,5% + 5% * 9%
P = 33,53%
En disposant du trafic light 6 et du pourcentage P de probabilité d’occurrence d’un incident de paiement, le commerçant peut alors décider d'accepter ou non le Chèque ou la Lettre de Change Normalisée 7. Si le commerçant décide d'accepter le Chèque ou la Lettre de Change Normalisée 7, la vente est conclue. Si le commerçant décide de ne pas accepter le Chèque ou la Lettre de Change Normalisée 7, la vente peut être annulée ou le client peut proposer un autre mode de paiement. En cas de perte ou de vol du Chèque ou de la Lettre de Change Normalisée 7, le commerçant peut être invité à contacter la banque 10 pour porter à sa connaissance que ce moyen de paiement perdu ou volé a été présenté chez ce commerçant. Dans un mode de réalisation de cette invention, la disponibilité des fonds dans le compte bancaire du client n'est pas affectée par le processus de vérification. Cependant, l'invention peut également être mise en pratique en vue du blocage du montant du Chèque ou de la Lettre de Change Normalisée 7 sur le compte bancaire du client au moment de la vente.
Les informations du compte bancaire extraites à partir de la piste CMC7 4 du Chèque ou de la Lettre de Change Normalisée 7 du client et celles reçues de la banque 10 du client peuvent éventuellement être enregistrées et utilisées avec un programme exécuté pour une remise à l’encaissement des Chèques et des Lettres de Change Normalisées 7 à la banque du commerçant pour paiement et compensation. L'utilisation des informations du compte bancaire du client précédemment enregistrées réduit le temps nécessaire au traitement des Chèques ou des Lettres de Change Normalisées 7 en fin de journée pour le commerçant. D'autres détails de la transaction tels que l'article ou le service acheté, la quantité et le prix peuvent être enregistrés pour produire des rapports à l'avenir. Bien qu'un mode de réalisation particulier de l'invention ait été décrit en détail à des fins d'illustration, on comprendra que des variations ou des modifications du procédé se situent dans le cadre des présentes inventions.

Claims

REVENDICATIONS Un procédé mis en œuvre par ordinateur pour vérifier auprès d'une banque le statut d'un compte sous-jacent à un Chèque ou une Lettre de Change Normalisée, détenu par un client (acheteur), lorsque cet instrument de paiement est présenté à un commerçant (vendeur), sur la base des informations du compte bancaire contenues dans la piste CMC7 visiblement imprimé sur un Chèque ou une Lettre de Change Normalisée, et comprenant les étapes:
■ Lecture de la piste CMC7 imprimée sur le Chèque ou la Lettre de Change Normalisée par un algorithme de reconnaissance d’image destiné à être téléchargé et utilisé par le commerçant sur son téléphone mobile ou sur son ordinateur connecté à un lecteur de chèque ou un scanner, dans un point de vente;
■ Extraction à partir de la piste CMC7 du numéro de compte du client et détermination du code de la banque, à contacter, par un algorithme de reconnaissance d’image et une table de recherche;
■ Enregistrement et conservation de l’image et de la data extraite du Chèque ou la Lettre de Change Normalisée par un algorithme sur le serveur du centre de traitement ;
■ Etablissement d’une communication sécurisée et instantanée avec le serveur de la banque du client sur la base du code de la banque, contenu dans la piste CMC7, par une table de recherche et un centre de traitement;
■ Envoi d’une requête de données sécurisées, basées sur le numéro de compte et le numéro du Chèque ou de la Lettre de Change Normalisée ainsi que le montant, par le serveur du centre de traitement au serveur de la banque.
■ Réception d’une réponse de données sécurisées correspondante à la requête envoyée, basée sur le numéro de compte et le numéro du Chèque ou de la Lettre de Change Normalisée ainsi que le montant, émise par le serveur de la banque à destination du serveur du centre de traitement.
■ Collecte et traitement de la data concernant les valeurs pour chacune de la pluralité des variables utilisées par un modèle de notation prédictif générant un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée.
■ Affichage sur le téléphone mobile du commerçant ou sur son ordinateur connecté à un lecteur de chèque ou un scanner d’un trafic light présentant les trois couleurs: Rouge, Orange, Vert avec une description bien détaillée pour chacune d’entre elles. Le trafic light est accompagné d’un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée généré par un modèle de notation prédictif. Un procédé selon la revendication 1 , caractérisé en ce que le centre de traitement comprend des moyens pour détecter, extraire et enregistrer les informations du compte bancaire du client contenues dans la piste CMC7 et du montant pour une utilisation dans un traitement futur de la transaction commerciale entre le commerçant et son client. Un procédé selon la revendication 1 , caractérisé en ce que les moyens utilisés permettent de stocker une pluralité de codes des banques; et d’établir par le serveur du centre de traitement d’une communication sécurisée et instantanée avec le serveur de la banque du client (acheteur) émetteur d’un Chèque présenté ou d’une Lettre de Change Normalisée présentée par ce dernier, au commerçant, sur la base des informations contenues dans la piste CMC7 et du montant sur ledit instrument de paiement. Un procédé selon les revendications 1 et précédentes, caractérisé en ce que les données sécurisées reçues du serveur de la banque du client permettent de vérifier le statut d'un compte bancaire sous-jacent à un Chèque ou une Lettre de Change Normalisée lorsque ledit instrument de paiement est présenté à un commerçant sur la base du montant et des informations de compte contenues dans une piste CMC7 visiblement imprimé sur chacun un Chèque ou une Lettre de Change Normalisée. Un procédé selon les revendications 1 et précédentes, caractérisé en ce que la data collectée concernant les valeurs pour chacune de la pluralité des variables utilisées est traitée par un modèle de notation prédictif permettant de générer un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée. Un procédé selon la revendication 5, caractérisé en ce que la data collectée et traitée par le modèle de notation prédictif permet d’afficher sur le téléphone mobile du commerçant ou sur son ordinateur connecté à un lecteur de chèque ou un scanner, une des trois couleurs: Rouge, Orange, Vert du trafic light avec un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée. Un système de traitement de données qui permet de vérifier auprès d'une banque le statut d'un compte sous-jacent à un Chèque ou une Lettre de Change Normalisée, détenu par un client (acheteur), lorsque cet instrument de paiement est présenté à un commerçant (vendeur), sur la base des informations du compte bancaire contenues dans la piste CMC7 visiblement imprimé sur un Chèque ou une Lettre de Change Normalisée, comprenant les moyens techniques :
■ Un algorithme de reconnaissance d’image et d’extraction du numéro de compte, du code de la banque du client du commerçant, du numéro du Chèque ou de la Lettre de Change Normalisée et du montant destiné à être téléchargé et utilisé par le commerçant sur son téléphone mobile ou sur son ordinateur connecté à un lecteur de chèque ou un scanner, dans un point de vente.
■ Un algorithme qui permet d’enregistrer et de conserver l’image et la data extraite du Chèque ou la Lettre de Change Normalisée sur le serveur du centre de traitement.
■ Une table de recherche contenant les codes bancaires et les coordonnées de contact correspondantes pour chaque banque comprenant notamment le token de sécurité pour établir une communication sécurisée avec le serveur de la banque du client.
■ Un algorithme qui permet de recevoir du serveur de la banque du client et d’enregistrer sur le serveur du centre de traitement les données sécurisées 14 qui correspondent à la requête envoyée, basée sur le numéro de compte et le numéro du Chèque ou de la Lettre de Change Normalisée et du montant.
■ Un modèle de notation prédictif qui permet de traiter la data collectée concernant les valeurs pour chacune de la pluralité des variables utilisées, pour générer un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée.
■ Un sous-programme logiciel qui permet l’affichage d’un trafic light sur le téléphone mobile du commerçant ou sur son ordinateur connecté à un lecteur de chèque ou un scanner présentant les trois couleurs: Rouge, Orange, Vert et d’un pourcentage de probabilité d’occurrence d’un incident de paiement d’un Chèque ou d’une Lettre de Change Normalisée.
PCT/MA2022/000009 2021-10-27 2022-06-13 Procede de verification instantanee des cheques et des lettres de change normalisees WO2023075581A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
MA54769A MA54769B1 (fr) 2021-10-27 2021-10-27 Procede de verification instantanee des cheques et des lettres de change normalisees.
MA54769 2021-10-27

Publications (1)

Publication Number Publication Date
WO2023075581A1 true WO2023075581A1 (fr) 2023-05-04

Family

ID=82067600

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/MA2022/000009 WO2023075581A1 (fr) 2021-10-27 2022-06-13 Procede de verification instantanee des cheques et des lettres de change normalisees

Country Status (2)

Country Link
MA (1) MA54769B1 (fr)
WO (1) WO2023075581A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001003081A1 (fr) * 1999-06-30 2001-01-11 Mcnaughton Alan G Systeme automatise d'execution des transactions comportant une pluralite d'interfaces utilisateurs
WO2009088272A2 (fr) 2008-01-11 2009-07-16 Sk Energy Co., Ltd. Procédé et dispositif de l'état de charge (soc) d'une batterie dans un système de gestion de batterie
US8165381B1 (en) * 2004-06-24 2012-04-24 Jpmorgan Chase Bank, N.A. Method and system for transaction decision making
US9740900B1 (en) * 2012-06-01 2017-08-22 Dadesystems, Inc. Systems and devices controlled responsive to data bearing records
US20180189870A1 (en) * 2002-05-14 2018-07-05 Early Warning Services, Llc Multi-database system for storing data from multiple data sources
US10552810B1 (en) * 2012-12-19 2020-02-04 United Services Automobile Association (Usaa) System and method for remote deposit of financial instruments

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001003081A1 (fr) * 1999-06-30 2001-01-11 Mcnaughton Alan G Systeme automatise d'execution des transactions comportant une pluralite d'interfaces utilisateurs
US20180189870A1 (en) * 2002-05-14 2018-07-05 Early Warning Services, Llc Multi-database system for storing data from multiple data sources
US8165381B1 (en) * 2004-06-24 2012-04-24 Jpmorgan Chase Bank, N.A. Method and system for transaction decision making
WO2009088272A2 (fr) 2008-01-11 2009-07-16 Sk Energy Co., Ltd. Procédé et dispositif de l'état de charge (soc) d'une batterie dans un système de gestion de batterie
US9740900B1 (en) * 2012-06-01 2017-08-22 Dadesystems, Inc. Systems and devices controlled responsive to data bearing records
US10552810B1 (en) * 2012-12-19 2020-02-04 United Services Automobile Association (Usaa) System and method for remote deposit of financial instruments

Also Published As

Publication number Publication date
MA54769A1 (fr) 2023-04-28
MA54769B1 (fr) 2023-07-31

Similar Documents

Publication Publication Date Title
US11049109B1 (en) Reducing false positives using customer data and machine learning
US11756009B1 (en) Apparatuses, methods and systems for a publishing and subscribing platform of depositing negotiable instruments
US7809614B2 (en) Tax transaction system
Mann Regulating internet payment intermediaries
US8396279B1 (en) Method and system for transaction decision making
US7624070B2 (en) Open payments target marketing system
US20050246234A1 (en) Automatic purchase categorization system
US20130062421A1 (en) Bar coded monetary transaction system and method
US20060080198A1 (en) Cash transaction system
JP2007528034A (ja) 販売時点における電子領収証の生成方法及びコンピュータ・プログラム
US12073408B2 (en) Detecting unauthorized online applications using machine learning
Chau et al. Anti-money laundering transaction monitoring systems implementation: Finding anomalies
FR3025915A1 (fr) Procedes et dispositifs de gestion de transactions composites
WO2023075581A1 (fr) Procede de verification instantanee des cheques et des lettres de change normalisees
US11854032B1 (en) Merchant services statements and pricing
Narsapur et al. An Analysis on the Rise in Digital Transactions in India
WO2005076855A2 (fr) Base de donnees de verification de titulaire de compte
Bogahawatte et al. Online Digital Cheque Clearance and Verification System using Block Chain
Lee et al. An Assistant Service for Customers in QR-payment with the Merchant Presented Mode
Ehramikar The enhancement of credit card fraud detection systems using machine learning methodology
CN112686655A (zh) 一种智能支付系统和方法
FR3011366A1 (fr) Methode de traitement de donnees transactionnelles, terminal, serveur et programmes d’ordinateur correspondants.
CN118379057A (zh) 一种直连收结汇及融资方法装置、设备及存储介质
CN114119199A (zh) 一种银行金融服务体验系统
WO2004034222A9 (fr) Procede et systeme de gestion de transactions financieres

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22730996

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 18705953

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE