EA041491B1 - METHOD AND SYSTEM FOR AUTOMATED CREDIT OF CASH IN THE EVENT OF FAULTS IN THE CHANNEL OF THE SELF-SERVICE DEVICE AT THE TIME OF CASH DEPOSIT - Google Patents

Description

Technical field

The invention relates to the field of computer technology, in particular, in data processing performed in the automated solution of problems of failures that occur in the channel of self-service devices (SS) when depositing cash.

State of the art

At the present time, when depositing cash into the RS, for example, an ATM, in order to credit the client's funds to the account in the event of failures, when the entire amount was not deposited into the RS, or was not fully recognized, it was necessary to contact the bank branch directly for a refund deposited funds (DS), or their subsequent transfer to the required account.

From the prior art, a solution is known aimed at automated recovery of a transactional request in the event of a failure in the RS channel when it is connected to a remote server (patent RU 2673982 C1, 03.12.2018).

The present invention is a refinement of the well-known solution in terms of analyzing the process of executing a transaction request directly in the RS channel itself, without being tied to a remote server, which makes it possible to implement a new function for automated processing of failures when depositing cash into the RS.

The essence of the invention

The claimed solution allows to solve the technical problem, which consists in creating a method for automated processing of failures when depositing cash into the RS. The technical result is to provide automated processing and crediting of DS to the client's account in the event of failures in the RS channel when depositing cash.

The claimed technical result is achieved due to a computer-implemented method of automated transfer of DS in the event of failures in the RS channel, implemented with the help of a processor and containing the steps at which a client's transaction request for cash deposit DS is received, containing at least data identifying the client, the amount transactions, account ID for crediting DS;

fix the occurrence of a failure in the contribution of the DS when executing a transactional request;

recognizing the sum of deposited DS in the SS channel after the occurrence of a failure by restoring the state of the DS cash depositing module of the SS;

fixing the input of the DS amount by the client for crediting to the account associated with the identifier in the transaction request;

comparing the amount of DS recognized in the RS channel and the amount entered by the client, and crediting the amount of recognized DS to the client's account associated with the identifier in the transaction request;

in the event of a discrepancy between the amounts of DS declared for deposit by the client and recognized by the RS, the amount of the claim is fixed and the amount of the claim is credited with the corresponding indications based on the results of checking the counters of the RS.

In one of the particular embodiments of the method, when restoring the state of the cash deposit module DS SS, banknotes are transferred to cash cassettes or cassette retract.

In another particular embodiment of the method, the account identifier is the card number or account number for crediting the DS.

In another particular embodiment of the method, the user's identifying information is transmitted using an NFC device.

The claimed solution is also implemented using a system for automated transfer of DS in the event of failures in the RS channel, containing at least one processor and at least one memory device that stores machine-readable instructions that, when executed by the processor, carry out the above method.

Brief description of the drawings

Fig. 1A illustrates an example of a CM circuit, FIG. 1B is an example of interaction between the client and the RS, fig. 2 is a block diagram of the claimed method, FIG. 3 is a general view of the computing device.

Implementation of the invention

The concepts and definitions necessary for a detailed disclosure of the claimed invention will be described below.

Cash (CS) is a specific product with the highest liquidity, serving as a measure of the cost of other goods and services.

Self-service banking device (CS) - a software and hardware complex designed for automated issuance and/or acceptance of cash by DS both with and without payment cards, as well as performing other operations, including payment for goods and services, drawing up documents confirming corresponding operations. Self-service banking devices

- 1 041491 are divided into two types depending on whether they support the cash dispensing function or not. If the function is supported, then the RS is an ATM (eng. automated teller machine), or an ATM, otherwise - NCS (non-cash systems), or a terminal for non-cash transactions.

Software (SW) - a program or a set of programs used to control the RS.

At each moment of time, the RS is in one of the following modes of operation:

Power Up - loading;

Offline - no connection with the server, connection is in progress;

Supervisor - a collector or service engineer works;

Out of service - RS does not work due to a malfunction, depletion of funds or forced transfer of the RS to the specified mode;

In service - the main operating mode of the US.

In the In service mode, the RS is in one of the states (state), with a number from 001 to 999 and a 25-character description string. The first character of this string is the state type (denoted by the letters A...Z, as well as a.z and some characters (,'.?)), which defines the collection. The remaining 24 characters are 8 decimal three-digit numbers, each of which is a specific state setting (screen number to display, conditions for switching to the state, list of actions). There can be any number of states of the same type.

The invention is implemented by the operation algorithm of the RS (100), which provides the function of depositing cash by the DS by the user (10). In FIG. 1A shows an exemplary diagram of the components of the CA (100). AS (100) can be an ATM, payment terminal and any other device that provides cash acceptance.

As shown in the presented general diagram of the CA (100), the device contains components integrated via a bus (software), such as a processor (101), memory (102), a networking tool (103), a display (104), controls (105 ), a DS issuing means (106), a DS receiving means (107), and a card reader (108). The processor SS (101) performs all the necessary computational operations when processing transactional requests. The memory (102) may represent one or more different types of devices such as RAM, ROM, or combinations thereof. HDD, SSD disks, flash memory, etc. can be used as ROM. The memory (102), as a rule, stores the program logic executed by the processor (101), which is necessary for implementing the method of operation of the CD (100), as well as the operating system that organizes the interaction interface (GUI) and data processing protocols.

As means of network interaction (103), devices can be used that provide data exchange using a wired or wireless type of communication, for example, an Ethernet card (LAN), a Wi-Fi module, a GSM modem (2G, 3G, 4G, 5G), etc. . Additionally, means of data exchange between the SS (100) and the user (user device) can be used, for example, a Bluetooth transceiver, an NFC module, IrDa, etc. The US display (104) serves to display a graphical user interface (GUI), and when it is executed in the form of a touch display, this also provides interaction with the user (10) and receiving control commands from him.

Controls of the US (105) can be a keyboard, touch screen, pin pad, mechanical and touch buttons, or a combination of the above elements. The DS dispenser (106) is a dispenser. The dispenser (106) can be of various types, such as friction or vacuum. The CD (100) also contains a means for receiving cash DS (107) from the user, in particular a bill acceptor or a cash accepting module.

The CA (100) also contains a bank card reader (108) that provides authorization of the client (10) and transition to the state to generate a transaction request for execution. The reader (108) can act as a card reader or an NFC module for contactless reading of customer cards (10).

US (100) may additionally contain a camera, one or more biometric sensors, a microphone. These devices, both individually and in combination, can be used to identify and verify the user.

In some embodiments of the technical solution, two-factor verification of the user can be used using a camera or biometric sensors, such as a fingerprint scanner, retina, or using analysis of the user's voice. Using the camera, an image of the user of the CA (100) can be captured for further processing and comparison with the reference identifying information of the account holder when a transaction is initiated in the CA (100).

The CD (100) can also provide for the exchange of identification information in a completely contactless mode using a pre-generated identification token using a user device, such as a smartphone, tablet or laptop, and its subsequent transmission over a wireless information exchange channel, such as Bluetooth, Wi-Fi, NFC , RFID, etc., in the US (100).

In FIG. 1B shows the general scheme of interaction between the user (10) and the RS (100). The primary user request to execute a transaction may be generated in the memory of the RS (100) after selecting

- 2 041491 banking operation client. The banking transaction can be selected by the user (10) by using the graphical user interface of the CD (100) displayed on the display of the CD (104). As a banking operation, this decision considers the deposit of cash DS for their subsequent crediting to the client's account (10) or other account. The CD (100) is connected via a data network (150), such as the Internet, with a remote server (120), which provides processing of data coming from the CD (100).

Next, with reference to FIG. 2, let's consider a block diagram of the claimed method (200) for automatically crediting cash deposited by the DS in the event of a failure in the RS channel (100).

The primary user request is formed by the interaction of the user (10) with the RS (100) and contains at least information about the user's intention to carry out a transaction for the delivery of the DS. When a primary user request is received in the system at step (201) to perform a transaction, a transaction request (102) is generated and stored in the RS memory (102), containing at least information identifying the client, the transaction amount, and the account identifier for crediting the DS. A unique transaction identifier (TrID) is generated for each transaction. In some embodiments, the transaction ID is a numeric or character value.

The TrID value must be unique for each transactional request (the TrID value is updated on each transition to a transactional state in the CA scenario). In all transactional requests, the field TransactionID is added, for example, with identifier 3, consisting of 12 characters.

For the initial request, these fields are formed as follows: YMMDDHHMMNNN (where Y is the last digit of the current year, MM is the month number, DD is the day, HH is the hour, MM is the minute, NNN is the last 3 digits of the current Accumulated Transaction Count value, which ensures uniqueness TransactionID values for this terminal). For a repeated request, the value of the TransactionID field must repeat the value generated at the time of the initial request.

When depositing cash DS at step (201), if a failure occurs in the channel of the RS (100), at step (202) the current state of the RS (100) is processed. Based on the features of each device model and numerous tests, the processing of mechanical errors when depositing cash allows you to use the indicator of deposited funds as close as possible to reality as a result of transactions, as well as to automatically restore the cash acceptance module (107). With the help of flexible settings of the cash acceptance module (107), it is possible to manage the following parameters:

cassettes into which banknotes are placed during failure processing: retract cassettes or cash cassettes (in this case, the ability of the module itself to transfer funds to cash cassettes is additionally analyzed);

the method of calculating the amount of recognized cash: from money that has finally entered the cassettes, or from money that has just passed validation;

the ability to launch the device recovery procedure (autorecovery) even if there is no money in the receiving drum (escrow).

The autorecovery procedure includes attempts to move banknotes into cash cassettes or into a cassette retract if, at the time of the error, the banknotes were left on the transport routes of the cash acceptance module (107), the receiving drum (escrow) or in the receiving compartment (pocket). In step (203) the CA (100) recognizes the amount of deposited DS that was fixed before the occurrence of the CA (100) failure. The amount of recognized DS is credited according to the client's identification details to his account (step 204).

If the client (10) deposited a larger amount than was credited to his account at step (204), then he generates the claim amount at step (205). The client using the GUI display (104) RS indicates the amount of cash that has not been credited to his account.

After the claim amount is formed, at step (206), the conditions for the possibility of crediting the DS amount entered by the client (10) to his account in automatic mode are checked. Verification of this condition can use various approaches, for example, compliance of the claim amount with a given threshold value for crediting, customer loyalty, frequency of similar requests in a given time period, etc. based on the transaction processing policy of a particular bank. To check these conditions, the CA (100) generates a data packet that is transmitted to the server (120) for its subsequent analysis, for example, by comparing records in the database for a particular client based on the historical information of previously performed transactions. The reliability of the client can be analyzed based on the presence of similar requests by this client (10) when working with other CAs (100). Also, for each CA (100) and/or client (10), the frequency of occurrence of similar situations is estimated, which may indicate that these actions have signs of fraudulent or malicious actions.

If the server (120) generates a response to the CA (100) about the successful completion of the verification of the request for crediting the claim amount, then the specified amount is credited to the client's account (step 208), otherwise

- 3 041491 case the amount is not credited and the client (10) is notified of the need to contact the bank for further processing of the claim (step 209). The claimed approach allows to reduce the number of requests for solving customer claims (10) arising from the failure of the RS (100) and provide a new function for automated crediting of funds. Also, the analysis of the recognized DS by the cash acceptance module allows to reduce the number of fraudulent transactions with the RS (100) and increase the processing speed of information flows to fulfill transactional requests. The automatic recovery function of the cash acceptance module (107) allows you to reduce the number of calls to the service team to resolve problems with the CA (100).

In FIG. 3 is a perspective view of a computing device (300) suitable for performing method (200). The device (300) may be part of the CA (100), the server (120), and other unrepresented devices that may participate in the overall information architecture of the claimed solution.

In the general case, the computing device (300) contains one or more processors (301) connected by a common information exchange bus, memory facilities such as RAM (302) and ROM (303), input/output interfaces (304), input/output devices ( 305) and a device for networking (306).

The processor (301) (or multiple processors, multi-core processor) may be selected from a variety of devices currently widely used, such as those from Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, and the like. The processor (301) may also be a graphics processor such as Nvidia, AMD, Graphcore, etc.

RAM (302) is a random access memory and is designed to store machine-readable instructions executable by the processor (301) to perform the necessary data logical processing operations. The RAM (302) typically contains the executable instructions of the operating system and associated software components (applications, program modules, etc.).

The ROM (303) is one or more persistent storage devices such as a hard disk drive (HDD), a solid state data drive (SSD), flash memory (EEPROM, NAND, etc.), optical storage media (CD-R/ RW, DVD-R/RW, BlueRay Disc, MD), etc.

Various types of B/B interfaces (304) are used to organize the operation of device components (300) and organize the operation of external connected devices. The choice of the appropriate interfaces depends on the specific implementation of the computing device, which can be, but not limited to, PCI, AGP, PS/2, IrDa, FireWire, LPT, COM, SATA, IDE, Lightning, USB (2.0, 3.0, 3.1, micro, mini, type C), TRS/Audio jack (2.5, 3.5, 6.35), HDMI, DVI, VGA, Display Port, RJ45, RS232, etc. To ensure user interaction with the computing device (300), various means (305) of B/B information are used, for example, a keyboard, a display (monitor), a touch screen, a touchpad, a joystick, a mouse, a light pen, a stylus, a touchpad, a trackball , speakers, microphone, augmented reality tools, optical sensors, tablet, light indicators, projector, camera, biometric identification tools (retinal scanner, fingerprint scanner, voice recognition module), etc.

The networking means (306) enables data to be transmitted by the device (300) via an internal or external computer network, such as an Intranet, Internet, LAN, and the like. As one or more means (306), an Ethernet card, a GSM modem, a GPRS modem, an LTE modem, a 5G modem, a satellite communication module, an NFC module, a Bluetooth and/or BLE module, a Wi-Fi module, and others

Additionally, satellite navigation tools in the device (300) can also be used, such as GPS, GLONASS, BeiDou, Galileo.

The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be interpreted as limiting other, particular examples of its implementation that do not go beyond the scope of the requested legal protection, which are obvious to specialists in the relevant field of technology.

Claims (7)

CLAIM 1. A computer-implemented method for automated crediting of funds (DS) in the event of failures in the channel of the self-service device (SS), implemented using a processor and containing the steps at which a client's transaction request for cash deposit DS is received, containing at least data identifying the client, the amount of the transaction, the account identifier for crediting the DS; fix the occurrence of a failure in the contribution of the DS when executing a transactional request; recognizing the sum of deposited DS in the SS channel after the occurrence of a failure by restoring the state of the DS cash depositing module of the SS; performing crediting of the amount of recognized DS to the client's account associated with the identifier in the transaction request, while said credit amount is less than the amount of deposited DS; - 4 041491 by means of the GUI of the display, the RS receives data on the amount of the claim to be credited to the client's account associated with the identifier in the transaction request; form by means of the RS a data packet to check the enrollment of the amount of the claim and transmit the mentioned data packet to the server for its subsequent analysis, and the RS and the server are interconnected via a data network; using the server to check the conditions for automatically crediting the amount of the claim to the client's account; if the server generates a response for the RS about successful verification of the request for crediting the claim amount, the claim amount is credited to the client's account. 2. The method according to claim 1, in which, upon restoring the state of the DS DS cash deposit module, banknotes are transferred to cash cassettes or a cassette retract. 3. The method according to claim 1, in which the account identifier is a card number or account number for crediting the DS. 4. The method of claim 1, wherein the user's identity information is transmitted using an NFC device. 5. The method according to claim 1, in which the conditions for automatically crediting the claim amount include checking at least one of the threshold value of the amount for crediting, the client's trustworthiness, the frequency of similar requests in a given time period. 6. The method of claim 5, wherein the claim amount is analyzed against a threshold set for the RS. 7. A system for automated transfer of DS in the event of failures in the RS channel, containing at least one processor and at least one memory device containing machine-readable instructions that, when executed by the processor, carry out the method according to any one of claims 1-6.