WO2013151459A1

WO2013151459A1 - Method for increasing the speed of payments

Info

Publication number: WO2013151459A1
Application number: PCT/RU2013/000133
Authority: WO
Inventors: Андрей Юрьевич ЩЕРБАКОВ; Олег Олегович ТИХОНЕНКО
Original assignee: Scherbakov Andrei Yuryevich; Tikhonenko Oleg Olegovich
Priority date: 2012-04-02
Filing date: 2013-02-20
Publication date: 2013-10-10
Also published as: EA201200411A1

Abstract

The invention relates to the field of finances and information technology, and more specifically to a method for increasing the speed of payments. The present invention can be used in the production and use of computer systems for different purposes, primarily financial systems intended for electronic settlements, and also commercial mobile communication systems. In comparison with all of the known methods for managing monetary funds which are known to the inventors, the proposed method differs in that it ensures a fundamental and substantial increase in the speed of payments when there is a temporary state of insufficient funds in the account.

Description

METHOD FOR INCREASING PAYMENT SPEED

Description

The invention relates to the field of finance and computer science, and more specifically to a method of increasing the speed of payments.

The present invention can find application in the creation and operation of computer systems for various purposes, primarily financial systems intended for electronic payments, as well as commercial mobile communications systems.

As you know, the most important parameter of the payment system is the speed of payments (see, for example, Baidukova N.V. Analysis and evaluation of organizational and technical support of payment systems, Problems of the modern economy, N 2 (22), 2007, http: //www.m -economy.ru/art.php?nArtId=1379).

However, it is known that when conducting electronic and non-cash payments related to the transfer of funds, a situation often arises when the funds in the participant’s account are insufficient to make such a transfer. At the same time, the dynamics of the account may be such that its liquidity, i.e. cash flow to it can be very positive. For example, manufacturing enterprises purchasing raw materials and selling products may have large revenues for the account for sold products, but at the same time, significant expenses for the purchase of raw materials. Often this process is random in nature, driven by global market conditions. In general, the inability to transfer funds associated with a temporary lack of funds in the account has very negative consequences for the stability of the financial system and the economy in general and significantly reduces the speed of payments.

On the other hand, lending mechanisms used to resolve situations of lack of funds are slow, in addition, lending by the bank may encounter both an objective lack of funds from the bank and subjective unwillingness of the bank to grant loans.

The present invention is based on the task of creating a method of increasing the speed of payments, which would allow for a high speed of payments with a temporary lack of funds in the account.

one

SUBSTITUTE SHEET (RULE 26) Closest to the invention under consideration is a solution in accordance with the Eurasian patent G) 11850 "Method of making payments through the payment system", which can be taken as a prototype. According to the aforementioned patent, payments are made through a payment system containing a payment processing means communicated with at least two payment participants sending and / or receiving funds through said payment system, according to which

- a payment participant sending money sends an order to the payment processor containing at least information about the amount of money that it intends to transfer and information about another payment participant to whom it intends to transfer money;

- the means for processing payments receives the specified order and performs one of the following actions:

- in the event that the amount of money available on the account of the payment participant sending the funds is not less than the amount of money specified in his order, the payment processing tool transfers funds from the account of the payment participant sending the money to the account of another payment participant, information about which is indicated in the order;

- if the amount of money available on the account of the payment participant sending the funds is less than the amount of money indicated in the order, then the payment processing tool puts the order on hold and transfers funds from the account of the payment participant sending the money funds to the account of another participant in the payments specified in the instruction, at the moment when additional payments are sent to the account of the participant of payments sending money redstv, the size of which in the amount with funds already available to the participant account payments, sending cash is not less than the amount of funds specified in the order.

Despite the fact that the prototype allows you to significantly increase the speed of payments between participants in payments, eliminates the need for continuous manual monitoring of the status of accounts of payment participants served by this payment system, and ultimately increases the convenience of using the payment system, nevertheless, the problem of continuity of payments with a temporary lack of funds on the account is finally not

2

SUBSTITUTE SHEET (RULE 26) it is decided because the payment is deferred until the funds are credited to the account, and if the funds received are insufficient or the payment has not been received during the business day, it will not be made. In addition, operational and bank-independent lending mechanisms for payment participants are not provided.

These problems are solved and the prototype’s disadvantages are eliminated in the method of increasing the payment speed implemented in accordance with the present invention in a system consisting of at least two participants having settlement accounts containing said funds and at least one control center also having a settlement account, comprising the fact that the participant in need of money declares this to the control center, informing him of the required amount of money, and the control center broadcasts this need to others Those who can transfer at least a part of the required amount of necessary funds from their settlement accounts directly to the account of the participant in need of funds, or through the settlement account of the control center, while the control center controls the term of the funds held by the participant to whom they were transferred, and returns money to the participants who have transferred them, and also charges a fee for using the transferred funds from the participant to whom they were transferred enes, and distribute at least a portion of the fee to participants who listed their money.

It is technically advisable to fix the maximum percentage of funds for each participant that can be transferred to the participant who needs money, since the stability of the payment system as a whole increases and the high payment rate for all participants remains.

No less technically feasible to transfer funds to the participant in need of them, based on a random selection of participants.

To justify the technical effectiveness of the proposed method, we consider the implementation of the layout of the payment system shown in Appendix 1. We fix the number of participants in the system and randomly set the amount of money in their accounts. Then, we cyclically simulate the operation of the system as follows. We define three events - debiting funds from an account, crediting funds to an account, and transferring funds from one participant to another, and we cyclically randomly consider these events with random amounts of money. The main characteristic of the effectiveness of a simulated payment system is the quantity

3

SUBSTITUTE SHEET (RULE 26) failures, when debiting from the account or transferring funds is impossible due to lack of funds and, accordingly, the speed of payments decreases. Then, in the event of a shortage of funds for the operation, we will implement the method described above. The following are the results of this simulation for a system layout of 15 participants and three rounds of a random number of payments specified by the Operations variable. Successful payments are reflected in the Good variable, and failures associated with a shortage of funds in the accounts are reflected in the Bad variable. The square brackets indicate the percentage of successful payments and the percentage of failures, respectively.

The results of the normal operation of the system:

Operations: 3073 Good: 2790 [90] Bad: 0283 [09]

Operations: 2049 Good: 1894 [92] Bad: 0155 [07]

Operations: 0329 Good: 0274 [83] Bad: 0055 [16]

Results using the described method:

Operations: 2689 Good: 2673 [99] Bad: 0016 [00]

Operations: 2817 Good: 2784 [99] Bad: 0033 [01]

Operations: 1377 Good: 1371 [99] Bad: 0006 [00]

It is easy to see that in the first case the relative number of failures is on average 10.6%, and in the second case, failures account for less than 1% of operations, i.e. the number of payments that cannot be made is reduced by more than 10 times and, accordingly, the rate of payments is growing as much.

Due to the implementation of the proposed method, it is possible to ensure a high payment rate with a temporary lack of funds in the account.

Compared with all known methods of cash management known to the authors, the proposed method is characterized in that it provides a fundamental and substantial increase in the speed of payments with a temporary lack of funds in the account.

four

SUBSTITUTE SHEET (RULE 26) Appendix 1. Layout of the payment system

#include <stdio.h>

#include <stdlib.h>

#include <io.h>

#include <string.h>

#include <time.h>

#include <conio.h>

#include <dos.h>

#include <dir.h>

#include <math.h>

#include "etalcry.c"

include "dsch.c"

#define N_AB 15

#define M_START 1000

#defme M_OPER 500

#define EV 3

#define PRIHOD 0

#defme RASXOD 1

#define PEREVOD 2

#define PRC BANK 1

#define PRC_CREDIT 15

int ab_schet [N_AB]; int aval [N_AB] [N_AB];

int cur_p [N_AB];

int x_ab [N_AB];

int y_ab [N_AB];

int delta [N_AB] [_AB];

int dist [N_AB] [N_AB];

int tg_s;

int prc (int a, int max)

5

SUBSTITUTE SHEET (RULE 26) {

return ((100 * (unsigned long) a) / (unsigned long) max);

}

int prc_b (int prcb, int oper)

{

return (oper * prcb / l 00);

}

int check_credit (int vol)

{

int i, sum;

sum = 0;

for (i = 0; i <N_AB; i ++)

sum = sum + prc_b (PRC_CREDIT, ab_schet [i]);

if (sum> vol) return (sum);

else return (-l);

}

void AppLogA (char * LogName, int all, int good, int prc_good_all, int bad, int prc_bad_all) {

FILE * out;

char ss [3] = {0xD, 0xA, 0};

out = fopen (LogName, "r + b");

if (out == NULL) out = fopen (LogName, "wb");

if (out == NULL) return;

fseek (out, 0, SEEKJEND);

fprintf (out, "Operations:% 04d Good:% 04d [% 02d]

Bad:% 04d [% 02d] ", all, good, prc_good_all, bad, prc_bad_all);

fwrite (ss, sizeof (char), 2, out);

fclose (out);

return

} main ()

{

6

SUBSTITUTE SHEET (RULE 26) int ij;

char cmd;

int all, bad, good;

int step, cc, tg_view, step_mov, tg_b = 0, global_p;

int events, ab_i, ab_j;

int oper;

int rez;

unsigned long allmoney;

unsigned long allbank;

int tg credit; all = l; good = 0; bad = 0;

allmoney = 0;

step = l; cc = 0;

init_dsch ();

// ... Set abonents random volume money

for (i = 0; i <N_AB; i ++) ab_schet [i] = rand_int (M_START);

allbank = rand_int (M_START);

// ... Main circle ...

while (cmd! = 27) {

clrscr ();

gotoxy (l, l);

cprintf ("Press any key for continue, press Esc for stop, f-fast, s-slow, c-credit"); events = rand_int (E V); ab_i = rand_int (N_AB);

for (i = 0; i <N_AB; i ++)

{

gotoxy (2,4 + i);

cprintf ("% 02d [% 06d]", i, ab_schet [i]);

}

if (events == PRIHOD)

7

SUBSTITUTE SHEET (RULE 26) {

oper = rand_int (M_OPER);

good ++;

allmoney = allmoney + oper;

ab_schet [ab_i] = ab_schet [ab_i] + oper;

gotoxy (l, 3);

cprintf ("PRIHOD Client =% 02d Summa =% 06d", ab_i, oper);

}

if (events == RASXOD)

{

oper = rand_int (M_OPER);

if (ab_schet [ab_i]> oper + prc_b (PRC_BANK, oper))

{

ab_schet [ab_i] = ab_schet [ab_i] -oper-prc_b (PRC_BANK, oper);

allbank-allbank + prc_b (PRC_BANK, oper);

good ++;

gotoxy (l, 3);

cprintf ("RASXOD Client =% 02d Summa =% 06d Percent =% 04d ^M , ab_i, oper, prc_b (PRC_BANK, oper));

}

else

{

if (tg_ credit == l)

{

rez = check_credit (oper);

if (rez! = - l)

{

good ++;

gotoxy (l, 3);

cprintf (CREDIT-RASXOD Client =% 02d Summa =% 06d Available =% 06d ", ab_i, oper, rez);

}

else bad ++;

8

SUBSTITUTE SHEET (RULE 26) }

else bad ++;

}

if (events == PEREVOD)

{

oper = rand_int (M_OPER);

abJ = rand_int (N_AB);

if (ab_i == abj) abJ = rand_int (N_AB);

if (ab_schet [ab_i]> oper + prc_b (PRC_BANK, oper))

{

ab_schet [ab_i] = ab_schet [ab_i] -oper-prc_b (PRC_BANK, oper);

allbank = allbank + prc_b (PRC_BANK, oper);

ab_schet [ab J] = ab_schet [ab J] + oper;

good ++;

gotoxy (l, 3);

cprintf ("PEREVOD [% 02d ->% 02d] Summa =% 06d Percent =% 04d", ab_i, abJ, oper, prc_b (PRC_BANK, oper));

}

else

{

if (tg_credit == l)

{

rez = check_credit (oper);

if (rez! = - l)

{

good ++;

gotoxy (l, 3);

cprintf ("CREDIT-PEREVOD Client =% 02d Summa =% 06d Available =% 06d", ab_i, oper, rez);

}

else bad ++;

}

9

SUBSTITUTE SHEET (RULE 26) else bad ++;

}

gotoxy (l, 2);

cprintf ("Events =% 04d Code =% 02d Good =% 04d [% 02d] Bad =% 04d [% 02d] Bank =% 06d", all, events, good, prc (good, all), bad, prc ( bad, all), allbank);

// ... End main circle

if (cc% step == 0) cmd = getch ();

cc ++;

if (cmd = - f) step = step * 2;

if (cmd == 's') {step = step / 2; if (step == 0) step = l;}

if (cmd = - c ') tg_credit = l;

if (cmd == 'n') tg_credit = l;

if (cmd == 27) break; .

cmd = 0;

all ++;

}

AppLogA ("bank.log", all, good, prc (good, all), bad, prc (bad, all));

return (O);

}

10

SUBSTITUTE SHEET (RULE 26)

Claims

CLAIM

1. A method of increasing the speed of payments in a system consisting of at least two participants having settlement accounts containing the said funds, and at least one control center also having a settlement account, in which the participant in need of funds , announces this to the control center, informing it of the amount of funds required for it, and the control center broadcasts this need to other participants who can transfer at least a portion of the required amount of necessary cash STV from their settlement accounts directly to Parties in need of cash or through the settlement account of the control center, the control center monitors the term is located. cash from the participant to whom they were transferred, and returns money to the participants who have transferred them, and also charges a fee for using the transferred funds from the participant to whom they were transferred, and distributes at least part of the fee to the participants who transferred their money .

2. The method according to p. 1, characterized in that the fixed percentage of funds for each participant is fixed, which can be transferred to the participant in need of funds.

3. The method according to p. 1, characterized in that the transfer of funds to the participant in need of them is based on a random selection of participants.

eleven

SUBSTITUTE SHEET (RULE 26)