WO2022124926A1

WO2022124926A1 - Method and system for the automated crediting of funds

Info

Publication number: WO2022124926A1
Application number: PCT/RU2020/000711
Authority: WO
Inventors: Дмитрий Владимирович КУЛИКОВ; Александр Андреевич КАРИЦКИЙ; Сергей Викторович КИЧАЕВ; Михаил Александрович МОИСЕЙКИН; Михаил Юрьевич ДОРОШЕНКО; Иван Геннадьевич НЕЦКИН; Сергей Суренович АЙРАПЕТЯН; Дмитрий Федорович СТАДНИК
Original assignee: Публичное Акционерное Общество "Сбербанк России"
Priority date: 2020-12-08
Filing date: 2020-12-16
Publication date: 2022-06-16
Also published as: RU2767285C1

Abstract

The invention relates to the field of computing. The claimed method consists of the steps of: receiving a client transaction request to deposit cash funds (hereinafter "cash"), containing client identification data, the transaction amount, and an identifier of the account to which the cash is to be credited; registering a failure occurring in the deposit of cash during execution of the transaction request; identifying the amount of inputted cash in a channel of a self-service device (SSD) after a failure has occurred by restoring the state of a module for the input of cash into the SSD; registering the introduction of an amount of cash by a client for crediting to the account associated with the identifier in the transaction request; comparing the amount of cash identified in the SSD channel and the amount introduced by the client, and crediting the amount of cash identified to the client account associated with the identifier in the transaction request. These actions allow the automated processing and crediting of cash to a client account in the event of a failure occurring in an SSD channel during the deposit of cash.

Description

METHOD AND SYSTEM FOR AUTOMATED CREDIT OF CASH

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 due to 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.

[OOP] The claimed solution is also implemented using 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 storing machine-readable instructions that, when executed by the processor, carry out 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) - a specific product with the highest liquidity, serving as a measure of the cost of other goods and services.

[0018] A self-service banking device (CS) is a software and hardware complex designed for automated issuance and / or acceptance of cash DS both with and without payment cards, 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 (English, automated teller machine), or an ATM, otherwise it is an 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 - there is no connection with the server, the connection is in progress;

Supervisor - a collector or service engineer works;

Out of service - the 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 mode of operation 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 line 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 US (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 CD (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 tool (106), a DS receiving tool (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), 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.

[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. The camera can capture an image of the user of the RS (100) for further processing and comparison with the reference identifying information of the account holder when initiating a transaction in the RS (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 other account.

[0032] The CD (100) is connected via a data network (150), such as the Internet, to a remote server (120) that processes data 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: FMM ]Q44MMNNN (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 value Count, which ensures that the value of TransactionID is unique 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.

[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 display (104) RS indicate 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. Checking this condition can use various approaches, for example, the compliance of the claim amount with a given threshold value for crediting, the client's trustworthiness, the frequency of similar requests in a given time period, etc. The threshold value for the amount of DC for crediting can be set both for the corresponding CA (100) and based on the transaction processing policy specific 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 to the CA (100) about the successful completion of the verification of the request to credit 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 that are widely used at the current time, for example, Intel™, AMD™, Apple™, Samsung Exynos™, MediaTEK™, Qualcomm Snapdragon™, 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, private examples of its implementation, not going beyond the requested legal protection, which are obvious to experts in the relevant field of technology.

Claims

FORMULA

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 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;

- compare the amount of DS recognized in the channel US and the amount entered by the client;

- fix the amount of the claim specified by the client, and check the conditions for automatic crediting of the amount of the claim to the client's account;

- transfer the amount of the claim to the client's account or notify the client of the need to contact the bank branch.

2. The method according to claim 1, in which, upon restoring the state of the cash deposit module of the DS SS, 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, wherein the user's identifying information is transmitted using an NFC device.

5. The method according to claim 1, in which the conditions for automatic crediting of the claim amount include checking at least one of: the threshold value of the amount for crediting, the reliability of the client, 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. A system for automated transfer of DS in the event of failures in the RS channel, comprising 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.