RU2767285C1 - Method and system for automated crediting of funds in case of failures in channel of self-service device at moment of cash deposit - Google Patents

Abstract

FIELD: physics.

SUBSTANCE: invention relates to computer engineering. Technical result is achieved due to the following stages: fixing the occurrence of a failure when depositing funds when executing a transactional request; recognizing the deposited amount in the channel of the self-service device after the occurrence of the failure by restoring the state of the cash depositing module of the self-service device; crediting the amount of recognized funds to the client's account associated with the identifiers of the transaction request, while said crediting amount is less than the amount of deposited funds; by means of the display GUI of the self-service device, receiving data on the amount of the claim to be credited to the customer account associated with the identifier in the transaction request; forming a data packet by means of a self-service device to check the enrollment of the claim amount and transmitting the said data packet to the server for its subsequent analysis, wherein the server and the self-service are interconnected via a data network; performing, using the server, checking the conditions for automatically crediting the claim amount to the client's account; if the server generates a response for the self-service device on successful verification of the request for crediting the amount of the claim, the amount of the claim is credited to the account of the client.

EFFECT: increasing the speed of processing information flows for executing transaction requests.

6 cl, 4 dwg

Description

FIELD OF TECHNOLOGY

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

BACKGROUND OF THE INVENTION

[0002] 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 directly to the bank branch to return the deposited funds (DS), or their subsequent transfer to the required account.

[0003] A solution is known from the prior art 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).

[0004] This solution is a refinement of the well-known solution in terms of analyzing the process of executing a transactional request directly in the RS channel itself, without being tied to a remote server, which allows you to implement a new function for automated processing of failures when depositing cash into the RS.

SUMMARY OF THE INVENTION

[0005] The claimed solution solves the technical problem of creating a method for automated processing of failures when depositing cash into the RS.

[0006] 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.

[0007] The claimed technical result is achieved through a computer-implemented method for automated enrollment of DS in the event of failures in the RS channel, implemented using a processor and containing the steps at which:

- receive a transaction request of the client for the cash deposit of the DS, containing at least data identifying the client, the amount of the transaction, the identifier of the account 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 cash deposit module DS 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

- perform the transfer of 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.

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

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

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

[0011] The claimed solution is also implemented using an automated DS enrollment system in case of failures in the RS channel, containing at least one processor and at least one memory device storing machine-readable instructions that, when executed by the processor, implement the above method.

BRIEF DESCRIPTION OF THE DRAWINGS

[0012] FIG. 1A illustrates an example of a CA circuit.

[0013] FIG. 1B illustrates an example of a client's interaction with the SS.

[0014] FIG. 2 illustrates a block diagram of the claimed method.

[0015] FIG. 3 illustrates a general view of a computing device.

IMPLEMENTATION OF THE INVENTION

[0016] The concepts and definitions necessary for the detailed disclosure of the claimed technical solution will be described below.

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

[0018] Self-service banking device (CS) - a software and hardware complex designed for automated issuance and / or acceptance of cash DS both using payment cards and without, as well as performing other operations, including payment for goods and services, compiling documents confirming the relevant transactions. Self-service banking devices 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.

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

[0020] At each moment in 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.

[0021] 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 3-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.

[0022] The claimed solution implements the algorithm of operation of the RS (100), which provides the function of depositing cash by the DS by the user (10). On 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.

[0023] As shown in the presented general diagram of the CA (100), the device contains components integrated via a bus (110), such as: a processor (101), a 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).

[0024] The CPU (101) performs all necessary computational operations when processing transactional requests. The memory (102) may represent one or more devices of various types, such as RAM, ROM, or combinations thereof. HDD, SSD disks, flash memory, etc. can be used as ROM. The memory (102) usually stores the software 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.

[0025] As a means of networking (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 as a touch display, it also provides interaction with the user (10) and receiving control commands from him.

[0026] The controls of the CD (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) may 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.

[0027] RS (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 be implemented as a card reader, or an NFC module for contactless reading of customer cards (10).

[0028] The CD (100) may further comprise 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.

[0029] In some embodiments of the technical solution, two-factor verification of the user can be applied using a camera or biometric sensors, for example, 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).

[0030] The CA (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, for example, a smartphone, tablet or laptop, and its subsequent transmission over a wireless information exchange channel, for example, Bluetooth , Wi-Fi, NFC, RFID, etc., in the US (100).

[0031] In FIG. 1B shows the general scheme of interaction between the user (10) and the CA (100). The initial user request to perform a transaction may be generated in the memory of the RS (100) after the client selects a banking transaction. 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 another account.

[0032] 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).

[0033] 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).

[0034] The primary user request is generated 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 CM memory, 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.

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

[0036] 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 value of Accumulated Transaction Count, which ensures that the TransactionID value is unique for a given terminal). For a repeated request, the value of the "TransactionID" field must repeat the value generated at the time of the initial request.

[0037] When depositing cash DS at step (201), when 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 makes it possible 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 (at the same time, 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).

[0038] 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 paths 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 DSs is credited to the client's account according to the client's identification details (step 204).

[0039] If the client (10) has 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 of the display (104) of the RS, indicates the amount of cash that has not been credited to his account.

[0040] After the formation of the claim amount, at step (206), the conditions for the possibility of crediting the amount of DS entered by the client (10) to his account in automatic mode are checked. Verification of this condition can use various approaches, for example, the compliance of the claim amount with a given threshold value for crediting, the reliability of the client, the frequency of similar requests in a given time period, etc. and based on the transaction processing policy of a particular bank. To check the specified 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.

[0041] 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.

[0042] If the server (120) generates a response for 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 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).

[0043] The claimed approach allows to reduce the number of calls to resolve 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 makes it possible to reduce the number of fraudulent transactions with the RS (100) and increase the speed of processing 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).

[0044] 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.

[0045] In general, the computing device (300) comprises one or more processors (301), memory devices such as RAM (302) and ROM (303), input/output interfaces (304), devices input/output (305), and a device for networking (306).

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

[0047] 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.).

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

[0049] Various types of I/O interfaces (304) are used to organize the operation of device components (300) and organize the operation of external connected devices. The choice of appropriate interfaces depends on the particular design 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.

[0050] To ensure user interaction with the computing device (300), various means (305) of I/O information are used, for example, a keyboard, a display (monitor), a touch screen, a touchpad, a joystick, a mouse, a light pen, a stylus, touch panel, trackball, speakers, microphone, augmented reality, optical sensors, tablet, indicator lights, projector, camera, biometric identification tools (retinal scanner, fingerprint scanner, voice recognition module), etc.

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

[0052] Additionally, satellite navigation tools in the device (300) can also be used, for example, GPS, GLONASS, BeiDou, Galileo.

[0053] The submitted application materials disclose preferred examples of the implementation of the technical solution and should not be construed 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 (14)

1. A computer-implemented method for automated transfer 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: - receive a transaction request of the client for cash deposit DS, containing at least data identifying the client, the amount of the transaction, the identifier of the account for crediting the DS, and the transaction request is generated and stored in the memory of the RS; - 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 cash deposit module DS SS; - perform the crediting of the amount of recognized DS to the client's account associated with the identifier in the transaction request, while the said amount of crediting is less than the amount of deposited DS; - 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 claim amount and transmit the said data packet to the server for its subsequent analysis, the server and the RS being interconnected via a data network; - using the server, 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 p. 1, in which, when the state of the cash deposit module of the DS SS is restored, the banknotes are transferred to the cash cassettes or the 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, in which the identifying information of the user is transmitted using the NFC device. 5. The method of claim. 1, in which the amount of the claim is analyzed for compliance with the threshold value set for the RS. 6. A system for automated enrollment 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 paragraphs. 1-5.

Images