Monitoring system and procedures for the electronic monitoring of financial transactions
Patent Information
- Application Number
- DE102023136361
- Authority / Receiving Office
- DE · DE
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2023-12-21
- Publication Date
- 2025-06-26
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
The proposed solution relates in particular to a monitoring system for the electronic monitoring of financial transactions.The electronic monitoring of financial transactions makes use of machine learning to an increasing extent, for example to assist financial institutions in the automated detection of anomalies in financial transactions. An anomaly is understood here to mean a deviation from a predetermined rule set which is indicative of a fraudulent financial transaction, in particular of at least one financial transaction used for money washing. In this case, electronic monitoring systems are intended to automatically filter out from several thousand financial transactions per day that part which is classified as suspect. An alarm event should then be generated for a financial transaction classified as suspect in order to be able to further check the respective financial transactions and, if appropriate, report them to a regulatory and / or ascertainment authority.However, elements of artificial intelligence (AI) are becoming increasingly important in this context, solutions for an efficient, cost-effective and accurate detection of anomalies in financial transactions are hardly known. This is where the proposed solution starts.In particular, a monitoring system for monitoring financial transactions is proposed, which electronically checks financial transactions between at least one payment-providing party and at least one payment-receiving party (or corresponding data relating to such financial transactions) for the occurrence of at least one anomaly. An anomaly is understood here to mean a deviation from a specific rule set which is indicative of a fraudulent financial transaction, in particular for a financial transaction used for money washing and therefore has to be classified as suspect on the basis of regulatory requirements. The proposed monitoring system is configured to generate an alarm event and thus an associated electronic alarm signal when detecting at least one such anomaly, which alarm signal triggers an alarm message, for example, at a (stationary or mobile) computer device of the monitoring system and / or at a computer device of a user system coupled to the monitoring system. The tokenizer is provided here to generate a token sequence from an input sequence representative of a financial transaction. The language model is in turn provided to check the occurrence of an anomaly in a financial transaction or multiple financial transactions for the generation of an alarm event on the basis of a token sequence or multiple token sequences.The proposed solution thus uses a language model which is provided here, however, not for the processing of natural language, but for the processing of tokenized input sequences for financial transactions. The proposed solution thus makes use of a language model which is based on a vocabulary for data relating to financial transactions instead of a vocabulary for natural language, in order to detect on this basis the extent to which anomalies are present in monitored financial transactions. These anomalies are here represented, for example, as deviations in an input sequence evaluated for a financial transaction or a data record corresponding thereto compared to a setup expected by the language model for the respective financial transactions.An import sequence contains transaction characteristics that can be distinguished from one another for each financial transaction. These transaction characteristics are treated in a string, which is supplied to the tokenizer as an input sequence, in the manner of words of a sentence in order to generate input tokens for the speech model therefrom. Tokenization of an input sequence is thus carried out on the basis of the transaction characteristics which have been taught in advance mechanically or manually. A transaction characteristic may be, for example, an account number, a business identifier code (BIC for short), a date, a time or an indicator for a type of transaction (for example, transfer or withdrawal).In one embodiment variant, the tokenizer is configured and provided to mask at least one input of the input tokens generated from the input sequence in a token sequence before the token sequence is transferred to the language model. The monitoring system is then further configured here to predict an output token for the at least one masked input token using the speech model. In this context, it can then be further provided, for example, that the monitoring system checks for the detection direction of an anomaly to what extent (in particular whether) the at least one predicted output token matches the associated input token. A prediction of the masked part is thus made via the speech model for the partially masked token sequence of a financial transaction. If the speech model cannot predict the masked input token or tokens, so that the output token does not match the original input token that was previously masked, it is concluded on the basis of the speech model trained on the basis of permissible financial transactions that a financial transaction or a money movement associated therewith is suspect and an anomaly is therefore present which, if appropriate taking into account further criteria, leads to the triggering of an alarm event.In this context, it can also be provided that a predefined, in particular percentage, proportion of input tokens is always masked, and the monitoring system is configured to check, for the detection of an anomaly, to what extent predicted output tokens correspond to input tokens associated with an output sequence for the financial transaction (i.e. which agree with respect to their position in the input sequence). If the masked input tokens of a financial transaction or a plurality of financial transactions cannot be correctly predicted by the language model, this is indicative of a suspect financial transaction or a plurality of suspect financial transactions.Alternatively or additionally, it can be provided that the monitoring system is configured, for the detection of an anomaly in a financial transaction, to compare the financial transactions with at least one cluster, which is formed on the basis of token sequences for financial transactions matching one another, on the basis of at least one reference input token of the token sequence associated with the financial transactions. In this embodiment variant, data relating to a financial transaction are consequently compared with one or more clusters with the aid of the language model and output token generated thereby and checked to what extent the respective financial transaction can be classified as belonging to a cluster. In this case, use is made of the fact that it has been recognized that financial transactions can be clustered by a language model in the case of a specific, matching transaction characteristic and therefore a reference input token resulting therefrom. If, however, a financial transaction with an identical reference input token is outside a cluster formed in this way beyond an allowed extent, this is indicative of a suspect financial transaction. It can be observed, for example, that financial transactions that are always comparable to accounts of a specific dealer category are carried out. For example, for a baker's account, there are typically a plurality of payment flows with comparatively small contributions from a plurality of different private accounts during the baker's opening time. A financial transaction which stands for a payment flow with an amount which is many times greater than an average value outside an opening time of the baker's area would therefore be outside a cluster formed for a baker's area and would therefore be classified as suspect-possibly with consideration of further criteria.Referring to the above-described embodiment, the reference input token used for clustering may each be an input token of a token sequence representative of a Characteristic Category Code (MCC) included in the input sequence.For example, it is provided that the monitoring system is configured to determine a data point for the comparison with the at least one cluster with the speech model on the basis of the at least one reference input token for the financial transaction and to determine its distance from a center of the at least one cluster. In such a procedure, multidimensional, in particular high-dimensional output vectors from the speech model are, for example, fed to a dimension reduction and then to a clustering function, and therefore to a clustering algorithm, in order to form a data point in the two-dimensional or three-dimensional space for an input sequence to a financial transaction, the distance of which data point from a center to different trained clusters can be determined. For the detection of an anomaly, this determined distance is compared with a stored threshold value. If the distance to a particular cluster or clusters is ultimately too great, a suspect financial transactions are inferred and an alarm event is generated.In one possible development, it can also be provided that different threshold values are stored for different clusters. Thus, for clusters of a specific first reference input token, a greater scatter of the data points for financial transactions can be permissible than in a cluster for financial transactions with a second reference input token different therefrom.For generating an alarm event, both criteria explained above can also be taken into account in principle. Thus, it can be provided that, for the detection of an anomaly, firstly a check is made as to the extent (whether) at least one predicted output token matches an associated masked input token, and secondly a check is made as to the extent to which a financial transaction can be associated with a specific cluster of financial transactions on the basis of an output token sequence. If the language model cannot predict the input tokens masked for a financial transaction correctly, for example, and the financial transaction cannot be reliably assigned to a specific cluster with the language model either, this is indicative of an anomaly and therefore of a suspect financial transaction which leads to an alerting event. If, if appropriate, only one of the aforementioned two criteria is indicated as indicating an anomaly, these can be weighted differently in order to decide whether or not the presence of one of the two criteria already leads to the generation of an alarm event.The speech model-based monitoring system may be, for example, a transformer machine learning model (thus a machine transformer learning model). In particular, this can be a transformer machine learning model trained on the basis of input sequences for financial transactions and in particular a bidirectionally trained transformer machine learning model. For example, a transducer machine learning model trained bidirectionally with bidirectional encoder representations from transformers, abbreviated to BERT, or another bidirectional encoder transformer has proven particularly advantageous in order to thus draw conclusions about anomalies in monitored financial transactions reliably and with comparatively manageable calculation complexity.In principle, the alarm event can be provided for output at a computer device of the monitoring system and / or at a computer device of a user system connected to the monitoring system. The monitoring system can thus be implemented, for example, on the server side, in particular in the cloud. The generated alarm event is in turn output at a local user system, for example a financial institution. Alternatively, an on-premium monitoring system may be provided. In particular, a computer device of a user system can comprise, for example, a mobile terminal, such as a laptop or a mobile telephone.The proposed solution further relates to a method for electronically monitoring financial transactions between at least one payment-providing party and at least one payment-receiving party for the occurrence of at least one anomaly. It is proposed here to generate a token sequence from an input sequence representative of a financial transaction in each case via a tokenizer and to check the occurrence of an anomaly in one or more financial transactions using a speech model on the basis of a token sequence or a plurality of token sequences in order to generate an alarm event in response to at least one anomaly detected during the check.An embodiment variant of a proposed method can be implemented in particular with an embodiment variant of a proposed monitoring system. Accordingly, advantages and features of execution variants of a proposed monitoring system explained above and below also apply to execution variants of a proposed method and vice versa.In particular, it can therefore be provided in an embodiment variant of the proposed method that the tokenizer masks at least one input token of the input tokens generated from the input sequence in a token sequence before the token sequence is transferred to the speech model in order to predict the at least one masked input token subsequently with the speech model and to check an output token generated for this purpose from the speech model to what extent this corresponds to the non-masked input token.Likewise, alternatively or additionally, for the detection of an anomaly, it can be provided that a check is made on the basis of at least one reference input token for a financial transaction as to the extent to which this financial transaction can be assigned to a cluster of comparable financial transactions using the language model.Furthermore, the proposed solution relates to a computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to execute an embodiment variant of a proposed method.Moreover, the proposed solution also relates to a method for training a language model for the monitoring of financial transactions. The proposed solution thus relates not only to the use of the already trained language model for the detection of anomalies in financial transactions. Rather, the focus is also on how a corresponding speech model can be trained. In this context, it is proposed that a corresponding training method comprises at least the following steps:providing data relating to individual financial transactions, typically each in the form of a string,generating at least a set of input sequences for the financial transactions, each input sequence including distinguishable transaction characteristics (typically predefined and provided as input to the language model);tokenizing the input sequences on the basis of the transaction characteristics using a tokenizer to generate input tokens for each input sequence;training the speech model on the basis of the input tokens and the input sequences by masking at least a part of the input tokens in order to provide a speech model trained on data relating to financial transactions, with which the occurrence of an anomaly in one or more financial transactions is detectable on the basis of a token sequence or a plurality of token sequences.In the proposed method, the training of the speech model is thus provided with the aim that the speech model correctly determines the masked input tokens from the context provided and thus checks to what extent output tokens generated with the aid of the speech model match input tokens which were previously provided only maskedly to the speech model. According to this aspect of the proposed solution, a (optionally pre-trained) language model is therefore used to learn a "vocabulary" on the basis of tokenized input sequences for financial transactions.In principle, in this context, it can be provided that the input tokens are each assigned to vectors of real numbers by means of word embedding ("embedding"). Previously, the tokenizer can convert the transaction characteristics into numerical input tokens. If, from the perspective of the language model, for example, a data record and therefore string characterizing a financial transaction can be used as word, a set of input sequences for a specific account and / or a specific dealer category describes a text with words characteristic thereof. As already explained above, the financial transactions on which the at least one set of input sequences are based can thus be assigned to an account of a specific dealer category code during the training of the language model. A set of input sequences then forms, for example, a "text example" for a specific type of account, which is identifiable on the basis of a reference input token (typically preceded by an input sequence). Separation or separation tokens can be provided between individual tokenized input sequences for the respective account, for example.Thus, for example, two input sequences for a specific account can be constructed as follows:(1) Trx1 Hp1 Cp019 2023-10-27:00:00:00 300 EUR CASH DEBIT ATM_WITHWAL DE MCC5892(2) Trx2 Hp1 Cp670 2023-10-30:01:10:08 600 EUR ACH CREDIT ACH_TRANSFER US MCC5892These input sequences can be represented as follows on the basis of predefined transaction characteristics:(3) 0D 0H 0M 0S AMOUNT2 CASH DEBIT ATM_WITHDRAWAL DE(4) 3D 1H 10M 8S MOUNT3 ACH CREDIT ACH_TRANSFER USHere, for example, the time ("2023-10-27:00:00:00") of the earliest financial transaction (1) is set as the zero point, and only the difference ("3D 1H 10M 8S") is used for date binding and time indication to the second financial transaction.Subsequently, the input sequences for financial transactions (1) and (2) are converted into a numerical representation as follows on the basis of formats (3) and (4).(5) 0 31 54 67 120 129 141 143 286(6) 3 32 65 74 121 132 140 148 232Assuming that the corresponding account relates to a dealer category code MCC with the value "523", an input token sequence can be represented by the tokenizer for this account as follows:[CLS] 523 [SEP] 3 32 65 74 121 132 140 148 232 [SEP] 0 31 54 67 120 129 141 143 286 [SEP] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PADHere, the token [CLF] constitutes a usual classification token. The reference [SEP] denotes a separation token which separates two input sequences from one another. A filling token ("padding token") is designated by [PAD] in order to bring a set of input token sequences for an account to a uniform size for all training data.Part of the tokenized transaction characteristics and thus of the numerical input tokens can also be a categorization parameter for the transaction volume of the respective financial transaction. Thus, an IBAN of a counterparty is typically different for each account being considered to which a financial transaction is considered. If an IMAN were thus transferred as a transaction characteristic, this would make it more difficult to transfer learned characteristics from one account to another account, since a different set of IMANs and thus input tokens are supplied with each account and its transaction characteristics under consideration. Against this background, in one embodiment variant, categorization or sorting according to transaction volume is provided. In this case, a set of input sequences containing a value for a categorization parameter is made available to the speech model to be trained for each account. The values for this categorization parameter depend on the transaction volume of the respective financial transactions with the account of the counterparty. A first value for this categorization parameter is always set identically for the account with the largest transaction volume, for example. For example, in this context, it may be provided that an input token "0" for the categorization parameter is always provided for the account having the largest transaction volume, and further input tokens having increasing values are set depending on the size of the transaction volumes occurring, e.g. an input token "1" for the second largest transaction volume, etc. This allows the language model to be better generalized from one account to the next account.For training the language model, a plurality of sets of input sequences can be generated, which are based on accounts with identical and different dealer category codes. On this basis, output vectors generated as output with the language model can be generated-after an optional dimension reduction and with the aid of a cluster function-clusters which are each representative of financial transactions of a dealer category code. These clusters can be used for a later comparison to what extent a financial transaction to be checked with a specific dealer category code can be assigned to a corresponding cluster for this dealer category code with the trained language model or, if appropriate, deviates so greatly from this that an anomaly can be assumed.In principle, the speech model to be trained can be a transformer machine learning model, in particular a transformer machine learning model pre-trained bidirectionally with BERT, an encoder transformer model based on BERT or another bidirectional encoder transformer model.The appended figures illustrate by way of example possible variants of the proposed solutionThe following are shown here: FIG. 1 is a schematic illustration of the monitoring system and its monitoring of financial transactions; FIG. 2 illustrates a set of input sequences for different financial transactions illustrating different transaction characteristics for a single transaction record; FIG. 3A shows the procedure for training a transformer machine learning model pretrained bidirectionally on the basis of input sequences according to FIG. 2 ; FIG. 3A shows the procedure for checking financial transactions for any anomalies on the basis of the trained language model; FIG. 4A illustrates visualization of different clusters for financial transactions determined using the trained speech model; FIG. 4B is a visualization for a data point determined with the speech model for a suspect financial transaction, illustrating distances of this data point to different clusters; FIG. 5A shows a schematic illustration for the assessment of the relevance of financial transactions on the basis of transaction characteristics or input tokens defined therewith; FIG. 5B is a schematic diagram for editing the relevance of different transaction characteristics of a financial transaction when generating an alarm event.FIG. 1 schematically shows an electronic monitoring system 1 with which financial transactions can be electronically monitored with the aid of a language model. In this case, data relating to a multiplicity of financial transactions, for example from a financial institution or a plurality of financial institutions, are made available to the monitoring system 1, or the monitoring system 1 is in use in a financial institution. FIG. 1 schematically shows financial transactions T1 to T4 for the account of a payment receiving E and therefore a favouriter. With each financial transaction T1 to T4, the payment receiving E receives payment flows at different levels from different payment providers S1, S2, S3. The financial streams are checked with the aid of the monitoring system 1 on the basis of the financial transactions T 1 to T 4 in order to identify electronically and automatically suspect cases in which an anomaly in the respective financial transaction and therefore, for example, a violation of regulations relating to money washing is violated.If an anomaly is detected in one of the financial transactions, the monitoring system 1 automatically generates an alarm event. This alarm event then leads, for example, to the output of an alarm message in order to indicate a case of suspected financial transactions T 1 to T 4. Such an alarm message is then output, for example, at a computer device of a user system 2 coupled to monitoring system 1 in the course of an anti-monocyte laundry ("anti-monocyte laundry").In one embodiment variant of the proposed solution, provision is made for data relating to each financial transaction T 1 to T 4 to be made available to a trained speech model of the monitoring system 1 as an input sequence SQ having mutually distinguishable transaction characteristics TC 1 to TC 5. An input sequence SQ corresponding to FIG. 2 has, for example, a transaction text TT and therefore a string which is composed of the plurality of transaction characteristics TC 1 to TC 5.A financial transaction T1 to T4 is unambiguously determined via the sum of the transaction characteristics TC1 to TC5. Thus, for example, a first transaction characteristic TC1 contains an indication of the account of the payment receiving E. A value for the transaction characteristic TC2 again stands for example for the type of financial transaction and indicates, for example, whether it is a withdrawal at an automated teller machine or a transfer. A further transaction characteristic TC3 specifies, for example, the account number of the payment provider S1, S2 or S3. The transaction characteristic TC4 identifies, for example, the bank directory number of the account of the payment provider S1, S2, S3. A transaction characteristic TC5 again contains information on the amount of money. Further transaction characteristics in turn indicate the date and time of the financial transactions.For training a language model of the monitoring system 1, a plurality of input sequences SQ can be provided for an account in the manner of words which are intended to be the basis for a vocabulary to be learned. From financial transactions for a single account, a mend of a plurality of financial transactions is randomly selected for this purpose in order to provide a transaction data record TS and therefore a set of input sequences SQ for the training.Both for training the speech model and for its later use, an input sequence SQ is tokenized in each case. The individual transaction characteristics TC1 to TC5 are converted into numerical input tokens w 1 to w 5 in this case.Thus, for example, two input sequences for the one account can be constructed as follows:(1) Trx1 Hp1 Cp019 2023-10-27:00:00:00 300 EUR CASH DEBIT ATM_WITHWAL DE MCC5892(2) Trx2 Hp1 Cp670 2023-10-30:01:10:08 600 EUR ACH CREDIT ACH_TRANSFER US MCC5892On the basis of the predefined transaction characteristics TC1 to TCn, these input sequences can be represented as follows:(3) 0D 0H 0M 0S AMOUNT2 CASH DEBIT ATM_WITHDRAWAL DE(4) 3D 1H 10M 8S MOUNT3 ACH CREDIT ACH_TRANSFER USHere, for example, the time ("2023-10-27:00:00:00") of the earliest financial transaction (1) is set as the zero point, and only the difference ("3D 1H 10M 8S") is used for date binding and time indication to the second financial transaction.Subsequently, the input sequences for financial transactions (1) and (2) are converted on the basis of formats (3) and (4) into a numerical representation for input tokens w 1 to w n as follows:(5) 0 31 54 67 120 129 141 143 286(6) 3 32 65 74 121 132 140 148 232Assuming that the corresponding account relates to a dealer category code MCC with the value "523", an input token sequence can be represented by the tokenizer for this account as follows:[CLS] 523 [SEP] 3 32 65 74 121 132 140 148 232 [SEP] 0 31 54 67 120 129 141 143 286 [SEP] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PAD] [PADHere, the token [CLF] constitutes a usual classification token. The reference [SEP] denotes a separation token which separates two input sequences from one another. A filling token ("padding token") is designated by [PAD] in order to bring a set of input token sequences SQ for an account to a size for a transaction data record TS that is uniform for all training data.Part of the tokenized transaction characteristics TC 1 to TCn and thus of the numerical input tokens can also be a categorization parameter for the transaction volume of the respective financial transaction T 1 to T 4. Thus, an IBAN of a payment receiving E is generally different for each account considered to which a financial transaction T1 to T4 is considered. If an IMAN were thus transferred as a transaction characteristic, this would make it more difficult to transfer learned characteristics from one account to another account, since with each account and its considered transaction characteristics TC1 to TCn, a different set of IMANs and thus input tokens w 1 to w n would be supplied. Against this background, in one embodiment variant, categorization or sorting according to transaction volume is provided. In this case, each account is assigned a value for a categorization parameter as part of a set of input sequences SQ which, in the example of FIG. 1, are made available to the speech model to be trained for a payment provider S 1 to S 3, and therefore to an account of a counterparty. The values for this categorization parameter depend on the transaction volume of the respective financial transactions T 1 to T 4 with the respective account (the counterparty). A first value for this categorization parameter is always set identically for that account of a payment provider S 1 to S 3 having the largest transaction volume, for example. For example, in this context, it may be provided that for the account with the largest transaction volume, an input token with the value "0" is always provided for the categorization parameter and further input tokens with increasing values are set depending on the size of the transaction volumes occurring, e.g. an input token "1" for the second largest transaction volume, etc. This allows the language model to be better generalized from one account to the next account.The training of the language model used in the monitoring system 1 for monitoring financial transactions T 1 to T 4 is illustrated in more detail with reference to FIG. 3A. A speech model 31 with a bidirectional transformer encoder is provided here. Input sequences SQ or a set of input sequences SQ is supplied to a tokenizer 10. This tokenizer 10 generates a token sequence with the input tokens w 1 to w 5. on the basis of the transaction characteristics TC1 to TC5 of each input sequence SQ for the financial transactions.For training the speech model 31, a certain portion of the input tokens w 1 to w 5 is now masked, illustrated by way of example in the example of FIG. 3 by replacing the input token w 4 with a masked token [MASK]. The token sequence is then fed to a word embedding 30 ("embedding") in order to prepare the token sequence for the speech model 31. This editing here includes the addition of the classification token [CLS], the separation tokens [SEP] and the fill tokens [PAD] explained above.A token sequence then passes through a transformer encoder level of the speech model 31; to form a partially masked token sequence, the speech model 31 generates multidimensional output vectors O1 to O5, from which output tokens w' 1 to w' 5 are obtained in a manner known per se for BERT, according to a classification 32 and subsequent vocabularyization 33. The outvectors O1 to O5 accordingly correspond to the respective input tokens w 1 to w5. The output vectors O 1 to O 5 consequently contain the context information of the respective input token w 1 to w 5, so that it is possible to learn in which context a specific transaction characteristic occurs. In classification 32, one or more classification layers are run through which generate probabilities for different classes in a classification task, so that output tokens for masked input tokens, such as an output token w' 4 for masked input token w 4 are subsequently concluded on the basis of a probability distribution and the already learned context. The language model 31 is consequently trained with a plurality of sets of input sequences SQ with the aim of closing masked input tokens such as the input token w 4 on the basis of the context, and therefore non-masked input tokens w 1, w 2, w 3, w 5. For example, 15% of the input tokens w 1 to w 5 can be randomly selected for the masking. Of these, i) 80% is replaced by a masked token [MASK] according to FIG. 3A, ii) 10% is replaced by a random input token and iii) 10% is left unchanged. By comparing the generated output tokens w' 1 to w' 5 with the token sequence of the input tokens w 1 to w 5 the speech model 31 is trained to predict input tokens correctly and thus to infer transaction characteristics TC1 to TC5.If the speech model is trained with corresponding training data, a trained speech model 34 corresponding to FIG. 3B is available for the efficient monitoring of financial transactions. For each financial transaction T1 to T4, an input sequence SQ is provided to the tokenizer 10 individually or as part of a set of a plurality of input sequences SQ for an account. A certain portion of the input tokens w 1 to w 5 is also masked here. As the transformer traverses the encoder plane of the trained speech model 34, high-dimensional output vectors O1 to O5 are generated, with which 4 output vectors are predicted for masked input tokens w. If predicted output tokens and thus an output token sequence deviate from the actual token sequence w 1- w 5 this indicates an anomaly in the respective financial transactions. In other words, it is checked to what extent previously masked input tokens for transaction characteristics are correctly predicted on the basis of the trained speech model 34. If this is not the case, the transaction characteristics TC1 to TC5 of a financial transaction deviate markedly from the rule rule. The respective financial transaction thus appears suspect and initiates an alarm event in order to further check it in more detail by a user or a control entity, for example in the case of a financial institution. A corresponding anomaly detection 35 is provided in FIG. 3B.The anomaly detection 35 can optionally additionally include that after a dimensional reduction of the high-dimensional output vectors O 1 to O 5 for a financial transaction, a data point is determined and compared with clusters generated during the training of the language model 31 for the financial transactions considered up to now.Thus, according to the visualization of FIG. 4, it can be shown that financial transactions classified as a reference input token for an account with a specific dealer category code MCC can be assigned with the language model 31 to different clusters C 1 to C 9 specific to dealer category codes. If, however, a data point A for a financial transaction corresponding to FIG. 4B is then not in the vicinity of one of these clusters C1 to C9, this also indicates an anomaly in the financial transaction which belongs to the data point A. For example, in the visualized example of FIG. 4B, the data point A is in each case spaced apart at a distance d 1 from a center M 1 of the one cluster C 8 and at a distance d 2 from a center M 2 of another cluster C 5 to such an extent that the distance d 1 is above a threshold value predefined for the cluster C 8 and the distance d 2 is above a threshold value predefined for the cluster C 5.If it is thus established, for example for a financial transaction with the aid of the trained language model 34, in the context of the anomaly detection 35 of FIG. 3B, that the language model 34 does not predict the token sequence w 1 to w 5 completely correctly and, in addition, a data point A determined for this purpose is not assigned to a previously determined cluster C5 or C8 for similar financial transactions, this is indicative of an anomaly and therefore of a suspect financial transactions which triggers an alarm event.In order to make a correspondingly triggered alarm event easier to evaluate in the course of the evaluation of a further test by a human user, a relevance evaluation 36 is also provided in the embodiment variant of FIG. 3B after the anomaly detection 35. In this case, those criteria which were decisive for the language-model-based assessment of a financial transaction as suspect are edited and visually displayed in a comprehensible manner to a human user when the alarm event is issued.Thus, for example, each financial transaction T1 to T4 can be represented as a sum of transaction characteristics or corresponding transaction tokens 500, 501, which are assigned to different groups 50 and 51. For example, the transaction tokens 500 together stand for a payment type 50 and the transaction dry 501 stand for a country code 51. By, for example, in the case of the financial transactions T 1, one of the transaction tokens 500 for the payment type 50 being classified as highly relevant-with regard to the detection of an anomaly-the financial transactions are provided with a relevance value ("import score") of 1. In contrast, the financial transaction T 3 contains a relevance value of 2, while the two further information items T 2 and T 4 shown are classified with the relevance value 3. In a visualization of the different financial transactions T 1 to T 4, the financial transactions T 1 are thus highlighted on a user system 2 as possibly more relevant for the more accurate observation of the occurrence of an anomaly. The trained language model 34 thus enables token-based explanation for the classification of various financial transactions as potentially suspect or un suspect.This principle is also based on a visualization according to FIG. 5B. Whereas for the visualization within the framework of the relevance assessment 36 according to FIG. 5A, token-based differences are visualized over a plurality of financial transactions T 1 to T 4, in a visualization according to the procedure of FIG. 5B, provision is made to visualize the different transaction characteristics within a financial transaction T 1 for a user of the user system 2, which have led to an assessment of this financial transaction T 1 as suspect and thus as detection of an anomaly. If, for example, output tokens of the trained language model 34 predicted on the basis of the transaction tokens 500, 501 and thus for the corresponding transaction characteristics can be concluded that there are considerable deviations with respect to financial transactions to be classified as permissible, especially in the payment type and country code, these can be weighted and visualized to this effect.Thus, for example, after the occurrence of a plurality of similarly conspicuous financial transactions, a user can be informed that, in the case of the alarm event triggered for an account, in particular on the basis of the financial transaction T 1, it was, for example, in each case proportionally decisive that smaller amounts have repeatedly taken place in a short sequence on a specific account of a payment receiving E, a large part of the transaction volume was in each case part of a round trip transaction and at least partially returned to a financial transaction exceeding the limit.By means of a visualization which is likewise token-based therewith, it is possible to improve the ability to be explained for a user of the monitoring system 1 considerably. This offers an additional advantage in the improved technique associated with the proposed solution for efficient electronic, automated monitoring of financial transactions on the basis of a language model, which can be implemented with comparatively low processor performance and high speed.List of reference characters1 Monitoring system 10 Tokenizer 2 User system 30 Word embedding / embedding 31 Pre-trained speech model / transformation encoder 32 Classification 33 Vocabularyization 34 Trained speech model 35 Anomaly detection and clustering 36 Relevance assessment 50 Payment type 500 Transaction tokens for payment type 501 Transaction tokens for country code 51 Country code A Data point for anomaly C1-C9 Cluster d1, d2 Distance E Payment-receiving I Relevance value M1, M2 Cluster center O1, O2, O3, O4, O5 Output vector S1, S2, S3 Payment-performing SQ Input sequence T1, T2, T3, T4 financial transaction TC1-TC5 transaction characteristic TS transaction data record (set of input sequences) TT transaction text w' 1, w' 2, w' 3, w' 4, w' 5 output token w 1, w 2, w 3, w 4, w 5 input token
Claims
Monitoring system for monitoring financial transactions (T1, T2, T3, T4), wherein the monitoring system (1) electronically checks financial transactions (T1, T2, T3, T4) between at least one payment-providing end (S1, S2, S3) and at least one payment-receiving end (E) for the occurrence of at least one anomaly and the monitoring system (1) is configured to generate an alarm event on detection of at least one anomaly, characterized in that the monitoring system (1) comprises a tokenizer (10) and a language model (34) for monitoring the financial transactions (T1, T2, T3, T4), wherein the tokenizer (10) is provided for generating an alarm event from one for a financial transaction (T1, T2, T3, T4) representative input sequence (SQ) is intended to generate a token sequence (w 1- w 5) and the language model (34) is intended to check the occurrence of an anomaly in one or more financial transactions (T1, T2, T3, T4) for the generation of an alarm event on the basis of a token sequence (w 1- w 5) or a plurality of token sequences (w 1- w 5).Monitoring system according to Claim 1, characterized in that the tokenizer (10) is set up and provided for masking, in a token sequence (w 1- w 5) at least one input token (w 4) of the input tokens (w 1, w 2, w 3, w 4, w 5) generated from the input sequence (SQ), before the token sequence (w 1- w 5) is transferred to the language model (34), and the monitoring system is configured, with the speech model (34), an output token (w' 4) for the at least one masked input token (w 4) is predicted.Monitoring system according to claim 2, characterised in that the monitoring system is configured to check, for the detection of an abnormality, to what extent the at least one predicted output token (w' 4) matches the associated input token (w 4).Monitoring system according to Claim 3, characterized in that the tokenizer (10) is set up and provided for masking a predefined proportion of the input tokens (w 1, w 2, w 3, w 4, w 5) in a token sequence (w 1- w 5) and the monitoring system is configured to check, for the detection of an anomaly, to what extent predicted output tokens (w' 1, w' 2, w' 3, w'4, w' 5) coincide with associated input tokens (w 1, w 2, w 3, w 4, w 5).Monitoring system according to one of the preceding claims, characterized in that the monitoring system (1) is configured, for the detection of an anomaly, to compare a financial transaction (T1, T2, T3, T4) on the basis of at least one reference input token (w 1) of the token sequence (w 1- w 5) associated with the financial transaction (T1, T2, T3, T4) with at least one cluster (C1-C9) which is formed on the basis of token sequences for financial transactions (T1, T2, T) with mutually matching reference input tokens (w 1).Monitoring system according to Claim 5, characterized in that the reference input token (w 1) is in each case an input token of a token sequence (w 1- w 5) which is representative of a dealer category code contained in the input sequence (SQ).Monitoring system according to Claim 5 or 6, characterized in that the monitoring system (1) is configured to check, for the detection of an anomaly, to what extent the respective financial transaction (T1, T2, T3, T4) can be assigned to the at least one cluster (C1-C9).Monitoring system according to one of Claims 5 to 7, characterized in that the monitoring system (1) is configured, for the comparison with the at least one cluster (C1-C9) with the language model (34), to determine a data point (A) on the basis of the at least one reference input token (w 1) for the financial transaction (T1, T2, T3, T4) and to determine its distance (d1, d2) from a centre (M1, M2) of the at least one cluster (C1-C9).Monitoring system according to Claim 8, characterized in that the monitoring system (1) is configured to compare the determined distance (d1, d2) with a stored threshold value for the detection of an abnormality.Monitoring system according to Claim 9, characterized in that different threshold values are provided for different clusters (C1-C9).Monitoring system according to one of Claims 8 to 10, characterized in that the monitoring system (1) for determining the data point (A) is configured to carry out a dimensional reduction for multidimensional output vectors (O 1- O 5) obtained from the speech model (34) for input tokens (w 1, w 2, w 3, w 4, w 5) of a financial transaction (T1, T2, T3, T4).Monitoring system according to one of Claims 3 or 4 and one of Claims 5 to 11, characterized in that, for the detection of an abnormality, the monitoring system (1) is configured, on the one hand, to check the extent to which the at least one predicted output token (w' 4) corresponds to the associated input token (w 4) and, on the other hand, to carry out a comparison with the at least one cluster (C1-C9) on the basis of the at least one reference input token (w 1).Monitoring system according to one of the preceding claims, characterized in that the speech model (34) of the monitoring system (1) is a transformer machine learning model, in particular a transformer machine learning model trained on the basis of input sequences (SQ) for financial transactions (T1, T2, T3, T4) and in particular a transformer machine learning model trained bi-directionally on the basis of input sequences (SQ) for financial transactions (T1, T2, T3, T4.Monitoring system according to one of the preceding claims, characterized in that the alarm event is provided for output at a computer device of the monitoring system (1) and / or at a computer device of a user system (2) connected to the monitoring system (1).Method for electronically monitoring financial transactions (T1, T2, T3, T4) between at least one payment-providing end (S1, S2, S3) and at least one payment-receiving end (E) for the occurrence of at least one anomaly, wherein an alarm event is generated in response to at least one anomaly detected during the checking, characterized in that an alarm event is generated from a financial transaction (T1, T2, which is transmitted for a financial transaction (T1, T2, T2) representative input sequence (SQ), in each case via a tokenizer (10), a token sequence (w 1- w 5) is generated and, using a speech model (34), the occurrence of an anomaly in one or more financial transactions (T1, T2, T) is checked for the generation of an alarm event on the basis of a token sequence (w 1- w 5) or a plurality of token sequences (w 1- w 5).A computer program product comprising instructions which, when executed by at least one processor, cause the at least one processor to perform the method of claim 15.Method for training a language model (31) for monitoring financial transactions, comprising at least the following steps: - providing data (TT) for individual financial transactions (T1, T2, T3, T4); - generating at least one set of input sequences (SQ) for the financial transactions, wherein each input sequence (SQ) contains transaction characteristics (TC1-TC5) which are distinguishable from one another; - tokenizing the input sequences (SQ) on the basis of the transaction characteristics (TC1-TC5) with a tokenizer (10) for generating input tokens (w 1- w 5) for each input sequence (SQ); training the speech model (31) on the basis of the input tokens (w 1, w 2, w 3, w 4, w 5) and the input sequences (SQ) by masking at least a part of the input tokens (w 1, w 2, w 3, w 4, w 5) in order to provide a speech model (34) trained on data relating to financial transactions (T1, T2, T2), with which the occurrence of an anomaly in one or more financial transactions (T1, T2, T) is detectable on the basis of a token sequence (w 1- w 5) or a plurality of token sequences (w 1- w 5).Method according to Claim 17, characterized in that the input tokens (w 1, w 2, w 3, w 4, w 5) are assigned vectors of real numbers by means of word embedding.Method according to Claim 17 or 18, characterized in that the tokenizer (10) converts the transaction characteristics (TC1-TC5) into numerical input tokens (w 1, w 2, w 3, w 4, w 5).Method according to Claim 19, characterized in that the financial transactions (T1, T2, T3, T4) on which the at least one set of input sequences (SQ) is based are assigned to an account of a specific dealer category code.Method according to one of Claims 17 to 20, characterized in that a multiplicity of sets of input sequences (SQ) are generated, these sets of input sequences (SQ) being based on accounts with different dealer category codes, and on the basis of multidimensional output vectors (O 1- O 5), generated as output by the language model (31), after a dimension reduction, clusters (C1-C9) are generated via a cluster function, said clusters being representative in each case of financial transactions (T1, T2, T3, T4) of a dealer category code.Method according to one of Claims 17 to 21, characterized in that at least one of the tokenized transaction characteristics (TC1-TC5) relates to a categorization parameter for a transaction volume of the respective financial transaction (T1, T2, T3, T4).Method according to claim 22, characterised in that values for the categorization parameter are predefined in ascending or descending order starting with a value for that account of a counterparty (S1-S3) which has the largest transaction volume in view of the data (TT) provided for the financial transactions (T1, T2, T3, T4) with an account.Method according to one of Claims 17 to 23, characterized in that the speech model (31) to be trained is a transformer machine learning model, in particular a bi-directionally pre-trained transformer machine learning model.Use of a monitoring system according to any one of claims 1 to 14 for monitoring financial transactions.
Citation Information
Patent Citations
Method for detecting anomaly and system thereof
KR1020230114157A
Customer transaction behavioral archetype analytics for CNP merchant transaction fraud detection
US20180053188A1
System, Method, and Apparatus for Determining a Geo-Location of a Transaction
US20200286094A1
Handling categorical field values in machine learning applications
US20200293878A1
Predictive data analysis techniques using bidirectional encodings of structured data fields
US20210406739A1