Payment system risk

Abstract

The present invention relates to methods and systems for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network. The method (300) comprises: receiving, at an intermediary party (304) of the payment system, a request (310) for a merchant to participate in the payment system, the request comprising identity details (312) of the merchant; comparing the identity details (312) of the merchant to a database (320) comprising existing card payment network details to identify existing card payment network details (322) of the merchant in the database; and determining, at the intermediary party (304) of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details (322) of the merchant. The present invention also relates to methods and systems processing a transaction request via a payment system, the payment system comprising a real time payment network.

Description

[0001] PAYMENT SYSTEM RISK

[0002] CROSS REFERENCE TO RELATED APPLICATION

[0003] This application claims the benefit of, and priority to, United Kingdom Patent Application No. 2410192.5, filed on July 12, 2024. The entire disclosure of the above application is incorporated herein by reference.

[0004] TECHNICAL FIELD

[0005] The present invention relates to methods and systems for reducing risk and detecting fraud in payment systems comprising a real time payment network.

[0006] BACKGROUND

[0007] Providers of card payment networks have developed and implemented a number of methods and systems for ensuring that transactions conducted via said networks are conducted safely and securely. In particular, systems have been developed that allow merchants that do not meet certain criteria to be flagged as ‘bad actors’ and for transactions to be assessed for a likelihood that they are fraudulent. These existing systems are often developed by collating and analysing many transactions, which is made possible by the fact that the use of card payment networks for conducting payment transactions is ubiquitous.

[0008] In recent years, alternative payment networks have begun to be adopted. These include domestic Account-to-Account (A2A) Real Time Payment (RTP) networks; mobile application-based systems that may provide RTP solutions. These alternative payment networks are particularly popular in developing countries and regions where traditional debit / credit cards are less prevalent and access to card payment networks is less widespread.

[0009] Although some security and anti-fraud protocols have been implemented on these A2A RTP networks, these may be less robust than the established systems that are used for card payment networks. This may particularly be the case during the adoption of new payment systems, where little data is available concerning the parties involved in the A2A RTP networks. Additionally, inconsistencies may arise between the different payment systems. A merchant may be flagged as a bad actor on databases for card payment networks, but not on databases for A2A RTP networks.

[0010] There is a need to improve risk analysis for payment transactions involving A2A RTP networks. Doing so can help provide for more secure transactions, e.g., by reducing the number of instances of fraudulent transactions. Additionally, the reliability of payment networks can be improved. More accurate risk analysis may reduce the number of legitimate transactions that are falsely identified as risky as a result of deficient data, for example.

[0011] The present invention seeks to address at least some of these needs, so as to provide for more secure and reliable payment transactions involving the use of RTP networks.

[0012] SUMMARY

[0013] According to an aspect of the invention, there is provided a computer implemented method for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment (RTP) network, the method comprising: receiving, at an intermediary party of the payment system, a request for the merchant to participate in the payment system, the request comprising identity details of the merchant; comparing the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details for the merchant in the database; and determining, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details for the merchant.

[0014] As part of an onboarding process to the payment system, it may be desirable to determine whether the merchant is a known ‘bad actor’ - e.g., a party to previous transactions that have resulted in negative outcomes. Doing so can help improve the security of the payment system, by reducing the number of bad actors operating on the system. This can result in reduced instances of fraudulent or non-optimal transactions (e.g., where purchased goods are faulty or are not delivered by the merchant). This can increase consumer confidence in the payment system.

[0015] RTP networks - for example account-to-account (A2A) networks that utilise mobile applications and / or digital transactions without the use of conventional, established card payment networks - may provide advantages for conducting payment transactions. RTP networks may enable funds to be transferred from the consumer to the merchant near instantaneously at the point of purchase. This is in comparison to conventional card payment networks, which typically involve a settlement process that may take up to one business day to complete, thereby causing a delay in the merchant receiving the funds. Examples of RTP networks include, but are not limited to, Pix (developed by the Brazilian central bank) and the Unified Payments Interface, UPI (developed by the National Payments Corporation of India, NPCI).

[0016] However, RTP networks (particularly during their early development and adoption) may lack the security robustness that has been developed for conventional payment networks. Prior to the onboarding of the merchant, there may be few or no identity details of the merchant associated with the RTP network. This may make it difficult to identify bad actors in the initial merchant onboarding phase. With no history of the merchant using the RTP network, an intermediary facilitating the onboarding may have to rely upon only identity details provided by the merchant as part of the participation request.

[0017] The present invention may advantageously allow existing card payment network details for the merchant to be used as part of the onboarding process. The existing card payment details may comprise sufficient information about the merchant to identify bad actors - the merchant may have an existing and extensive history of payment transactions conducted via the card payment network (i.e., a conventional payment network). Therefore, by comparing the identity details of the merchant to the database comprising existing card payment network details, the intermediary party may be able to leverage the more extensive information that exists regarding the merchant’s card payment network history. This may enable the intermediary party to more accurately determine whether the merchant should be onboarded to the payment system comprising a real time payment network.

[0018] The database may comprise previous transaction information for past payment transactions involving the merchant conducted via the card payment network. Comparing the identity details of the merchant to the database may comprise identifying past payment transactions involving the merchant that resulted in a non-optimal transaction outcome.

[0019] A non-optimal transaction outcome may be a payment transaction that results in a negative outcome for some party involved in the payment transactions (discussed below). By comparing the identity details of the merchant to the database, it may be possible to establish whether the merchant is a bad actor. Where the number of non-optimal transactions in the database exceeded a certain amount or a certain frequency (e.g., a predetermined number of non-optimal transactions over a given time period), it may be determined that the merchant is a bad actor. The intermediary party may then act accordingly, e.g., by refusing to onboard the merchant to payment system.

[0020] The database may comprise existing card payment network details for merchants that have been determined to be high risk based on past payment transactions. The database may comprise a reason parameter, the reason parameter corresponding to a reason why the merchant in question was included in the database. Comparing the identity details of the merchant to the database may comprise retrieving the reason parameter.

[0021] Instead of, or in addition to, the database comprising information regarding past payment transactions involving the merchant conducted via the card payment network, the database itself may comprise identity details of merchants already determined to be bad actors. The database may be a proprietary database collated by a card payment network provider, based upon past payment transactions involving the merchant conducted via the card payment network. The database may comprise a list (with associated identity details) of merchants that are restricted in using the card payment network.

[0022] The reason parameter may comprise one or more codes that indicate a behaviour of the merchant in past payment transactions conducted via the card payment network that resulted in said merchant being included in the database. These codes may be stored in the database as part of the existing card payment network details for the merchant. The behaviour may be a repeated behaviour that may signify issues in the merchant’s operations (either the goods / services provided by the merchant themselves, or their financial practises) or a single instance whether the merchant has failed to comply with necessary standards / procedures (either legal requirements or standards imposed by the card payment network provider). For example, a code may indicate that: i) the merchant has received excessive chargebacks via the card payment network - e.g., the number of chargebacks in any single month exceeded 1% of the number of payment transactions in that month, and those chargebacks totalled USD 5,000 or more; ii) the merchant has affected an excessive number of fraudulent transactions (counterfeit or otherwise) - e.g., the merchant’s fraud-to-sales dollar volume ratio was 8% or greater in a calendar month, and the merchant effected 10 or more fraudulent transactions totalling USD 5,000 or more in that calendar month; iii) the merchant has been involved in a data protection breach - the merchant is responsible for a compromise (either directly or indirectly) in account data, or account data was stolen at the merchant and then used for fraudulent purchases at other merchant locations; iv) the merchant has been involved in criminal / illegal activity - e.g., money laundering, collusion, illegal transactions or identity theft; v) the merchant does not meet necessary standards - e.g., insufficient auditing processes, non-compliance with card payment network standards, insufficient data security procedures; and / or vi) other financial difficulties - e.g., the merchant is bankrupt or insolvent.

[0023] By retrieving the reason parameter, the intermediary who is conducting the onboarding may be able to easily determine whether or not to onboard the merchant. The database may comprise information in addition to the codes, such as additional comments detailing why the merchant was added to the database. The database may comprise existing card payment network details for one or more principals acting on behalf of the merchant. The identity details of the merchant may comprise identity details of one of said principals. Determining whether the merchant should be onboarded to the payment system may comprise: determining whether the principal whose identity details are contained in the request should be onboarded to the payment system: or determining whether the merchant and each principal should be onboarded to the payment system.

[0024] Although described above as comparing identity details of a merchant, the merchant may in reality comprise a plurality of principals acting on their behalf. For example, the merchant may be a chain of stores, where each store is a principal that conducts payment transactions on behalf of the merchant. The database of existing card payment network details may comprise details for one or more principals. For example, where the database comprises identity details of merchants already determined to be bad actors (based upon past payment transactions involving the merchant that resulted in a non-optimal transaction outcome), said identity details may include identity details of said principal(s) associated with the non-optimal transaction(s). The identity details may include a name, address, contact details and / or additional identifying information for the principal.

[0025] When determining whether the merchant should be onboarded to the payment system, the determination may be done on a principal-by- principal basis. For example, the merchant may not be prevented from onboarding per se, but principals that are identified in the database may not be included in the onboarding; certain stores / locations of the merchant may be onboarded while others are not. Alternatively, the merchant as a whole, including all principles, may not be onboarded, depending on the determination of the intermediary.

[0026] The identity details of the merchant may comprise a government-controlled identifier. Identifying the existing card payment network details for the merchant may be based at least in part on the government-controlled identifier. The existing card payment network details for the merchant may comprise the same government-controlled identifier, meaning that this identifier may provide a suitable means for identifying the merchant within the database. The government-controlled identifier may be an identification linked to a corporate entity or an individual, such as a tax code / number. The government-controlled identifier may be included directly in the request for the merchant to participate in the payment system (e.g., having been input by the merchant during the onboarding request). The government-controlled identifier may represent an advantageous means of performing the comparison and identifying existing card payment network details for the merchant, as it may be unique and / or centrally controlled. Alternatively, the government- controlled identifier may be retrieved by the intermediary based upon other identity details contained in the request. Where the existing card payment network details for the merchant do not comprise the government-controlled identifier, the comparison may be performed by comparing / identifying other details of the merchant, such as a name or an address.

[0027] The intermediary party may be a payee payment service provider (PSP). Determining whether the merchant should be onboarded to the payment system may comprise determining whether the payee payment service provider should allow the merchant to be involved in future payment transactions to be conducted at least in part via the real time payment network.

[0028] The method of the present invention may enable the payee PSP to determine more accurately whether the merchant should be allowed to use the RTP. The merchant may have little or no transaction history regarding the RTP network upon which the onboarding determination can be conducted. But by comparing the identity details of the merchant to the database comprising existing card payment network details, the payee PSP may be able to more reliable identify bad actors. This may reduce the number of fraudulent or otherwise negative transactions that are conducted via the payment system. The method of the present invention may reduce the number of false positives associated with an onboarding process, a false positive representing an instance where the merchant is falsely determined to be a bad actor. The intermediary party may be a custodian of the real time payment network. Determining whether the merchant should be onboarded to the payment system may comprise determining whether the identity details of the merchant should be stored.

[0029] The custodian may be a central bank or other financial institution, for example, who has regulatory control over the RTP network. Prior to onboarding, the merchant may have no history of using the RTP network and so have no data stored in relation to the RTP network. The method of the present invention may be used to initially register the merchant as part of the onboarding - e.g., the custodian may store and / or retrieve identifying details for the merchant. These stored details may then be used for ongoing purposes, such as fraud monitoring.

[0030] The computer implemented method may further comprise, if it is determined that the merchant should be onboarded to the payment system, generating a proxy identity for the merchant associated with the real time payment network.

[0031] Where the merchant is onboarded to the payment system, they may be provided with a proxy identity that identifies them on the RTP network. The proxy identifier may be a username or an ID that is associated with the merchant and utilised in future payment transactions conducted at least in part via the RTP network.

[0032] According to another aspect of the present invention, there is provided a computer implemented method of processing a transaction request via a payment system, the payment system comprising a real time payment network, the method comprising: receiving, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction; comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network; determining, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network; and generating, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

[0033] Similar to the computer implemented method of onboarding discussed above, the security of payment transactions conducted using a payment system comprising a RTP payment network can be improved by the present invention. Additional information that may exist with regards to conventional payment networks (e.g., previous payment transactions conducted via a card payment network) may be leveraged when processing payment transactions conducted via the payment system comprising the RTP network. Whereas information regarding previous payment transactions (particularly transactions involving the consumer and / or the merchant using the RTP network may be inadequate, e.g., during the early development and adoption of the RTP network), the database of previous payment transactions conducted via the card payment network may be used instead or additionally. Thus, the security of payment transactions (e.g., detection of fraudulent transactions), may be improved compared to utilising only RTP network databases / information.

[0034] The database of previous payment transactions conducted via the card payment network may be a proprietary database collated by a card payment network provider. The database may comprise a list of previous payment transactions conducted via the card payment network that are known to be fraudulent (over a given time period or all such previously fraudulent payment transactions). The database may have been generated by collating payment transactions that have been reported other by parties involved in said payment transactions, e.g., payment transactions that have been reported as fraudulent by an issuer / payer bank. The fraudulent payment transactions may be stored in the database in a standard transaction format so that they can be queried (e.g., during the comparison on the payment details of the consumer and / or merchant to the database of database of previous payment transactions conducted via the card payment network). For example, the database may comprise previous payment transactions sorted in ISO8583 transaction fields.

[0035] The identified previous payment transactions conducted via the card payment network may be previous transactions that involve the consumer and / or the merchant (i.e., transactions where the consumer and / or merchant were a party to the transaction). Identifying such transactions may provide a convenient method for determining the likelihood that a new transaction is fraudulent. The database of previous payment transactions conducted via the card payment network may be queried using identifying details of the consumer and / or merchant provided in the transaction request - e.g., a name, addresses, contact details, financial information (e.g., account or card number) and / or a government-controlled identifier (e.g., a tax code or social security number). Where the database of previous payment transactions is a database of known fraudulent previous transactions, identifying the consumer / merchant in said previous payment transactions may indicate that the consumer and / or merchant has previously been involved in fraudulent activity.

[0036] However, identifying previous payment transactions conducted via the card payment network may not, or may not solely, comprise identifying previous payment transactions conducted via the card payment network that involve the consumer and / or the merchant. The identified previous payment transactions may not directly involve either the consumer or the merchant.

[0037] The database of previous payment transactions may be generated using Machine Learning Fraud Analysis (based on previous datasets); an Al machine learning engine may be trained with a subset of previous payment transaction data to identify data patterns within the database that may indicate a link between the consumer and / or merchant (based on the payment details provided in the transaction request) and previous payment transactions conducted via the card payment network, even where said consumer / merchant payment details do not explicitly appear in the database. Any Al / machine learning based-approach may be used for this. Comparing the payment details of the consumer and / or the merchant to the database of previous payment transactions conducted via a card payment network may comprise providing said payment details to a machine learning engine that has been trained to perform the identification. The computer implemented method of the present invention may call the machine learning engine via an application programming interface (API), for example. The machine learning engine may be developed and / or operated by a third party, such as the card payment network provider.

[0038] For example, a fraudulent party may have devised a way to programmatically capture and take control of payment accounts (e.g., by capturing primary account numbers and obtaining an associated encrypted authorisation value / key). Any new transactions that are initiated by the fraudulent party using the captured payment accounts may not correspond to consumer / merchant details in the database of previous payment transactions; the fraudulent party may in fact try and capture ‘clean’, low-risk accounts in order to avoid suspicion. Nonetheless, previous payment transactions conducted via the card payment network that are associated with the fraudulent party may still be identified based on details provided in the transaction request. Data patterns within the previous payment transactions - for example, the type of transaction, any recurrence of transactions, or the type of payment card / account used - may be used for the methods herein.

[0039] The present invention may therefore advantageously provide for improved fraud detection in payment systems comprising RTP networks. By utilising the database of previous payment transactions conducted via the card payment network (e.g., previous payment transactions conducted via the card payment network that are known to be fraudulent), the probability of identifying that the new payment transaction on the payment system comprising a real time payment network is fraudulent may be increased. Data associated with the RTP network may be insufficient for detecting fraud (particularly for new RTP networks where the consumer and / or merchant have little transaction history), but the corresponding data associated with card payment networks (where the consumer and / or merchant may have more transaction history, given that the card payment network is a conventional, established network) may supplement this. If the determined fraud risk parameter exceeds a predetermined threshold, the transaction output may comprise instructions to terminate the new payment transaction.

[0040] The fraud risk parameter is related to the to the likelihood that the new payment transaction is fraudulent, but may be computed in a number of different ways and / or take a number of different forms. For example, the total number of identified previous payment transactions conducted via a card payment network involving the consumer and / or merchant that have taken place in a given time period may summed. Based upon this summed value, the fraud risk parameter may be determined - if no fraudulent transactions are identified the fraud risk parameter may be low, if many fraudulent transactions are identified, the fraud risk parameter may be high. The fraud risk parameter may be the summed value itself, a numerical value representing this sum, or a percentage indicating the determined likelihood that the new payment transaction is fraudulent.

[0041] The fraud risk parameter may be based upon other factors, not just the number of instances of previous payment transactions conducted via a card payment network involving the consumer and / or merchant that are identified in the database. For example, recency and / or frequency of said previous payment transactions or the amount of money involved in the new and / or previous payment transaction may contribute to the likelihood of the new payment transaction being fraudulent. Determining the fraud risk parameter may comprise using existing methods and rules that have been developed by the card payment network provider for identifying instream fraud. These methods may comprise the use of Al models that have been trained on a subset of the database of previous payment transactions conducted via a card payment network that are known to be fraudulent.

[0042] Where the determined fraud risk parameter exceeds a predetermined threshold, the transaction output may comprise instructions to terminate the new payment transaction. The instructions may comprise instructions to provide a termination message to the consumer (e.g., via a point-of-sale terminal), informing them that the transaction request has been terminated. Thus, new payment transactions that are suspected to be fraudulent may be blocked. The computer implemented method may further comprise comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via the real time payment network to identify a previous payment transaction conducted via the real time payment network. The fraud risk parameter may also be based on the identified previous payment transactions conducted via the real time payment network.

[0043] Although the present invention relates to using the database of previous payment transactions conducted via a card payment network to improve fraud detection capabilities, there may also exist useful information relating the RTP network. Therefore, in addition to the above, the method may also make use of a corresponding database of previous payment transactions conducted via the real time payment network. Similar to above, this database may comprise details / statistics for previous payment transactions conducted via the RTP network that are known to be fraudulent. Using both the database of previous payment transactions conducted via the card payment network and the database of previous payment transactions conducted via the RTP network may improve the accuracy of determining the fraud risk parameter.

[0044] The computer implemented method may further comprise: updating the database of previous payment transactions conducted via the real time payment network to include the identified previous payment transactions conducted via the card payment network; and / or updating the database of previous payment transactions conducted via the card payment network to include the identified previous payment transactions conducted via the real time payment network.

[0045] Updating either of the databases to include previous payment transactions (e.g., transactions involving the consumer and / or merchant) identified in the other database may improve synchronisation between the databases and between fraud detection on the card payment network and the RTP network. The two databases may have the same or similar fields, and so synchronisation of the databases may be performed easily. The synchronisation may comprise calling an application programming interface (API) associated with each of the database of previous payment transactions conducted via the card payment network and the database of previous payment transactions conducted via the RTP network.

[0046] The database of previous payment transactions conducted via the real time payment network and / or the database of previous payment transactions conducted via the card payment network may comprise a government-controlled identifier for the merchant and / or the consumer.

[0047] Similar to described above for the onboarding process, the databases of previous payment transactions may comprise a government- controlled identifier. The government-controlled identifier may be an identification linked to a corporate entity or an individual relating to their domestic finances, such as a tax code / number. The transaction request may comprise the same government-controlled identifier as part of the payment details for the consumer and / or the merchant. The government-controlled identifier may therefore provide an advantageous means of performing the comparison and identifying previous payment transactions involving the consumer and / or merchant in either of the databases, as it may be unique and / or centrally controlled. Other payment details of the consumer and / or merchant may be used for the comparison / identification, such as a name or an address.

[0048] The payment details of the consumer may comprise a proxy identifier for the consumer. A payer payment service provider (PSP) may maintain a relationship between the proxy identifier of the consumer and the government-controlled identifier of the consumer.

[0049] The government-controlled identifier of the consumer (e.g., tax code / number) may not be included in the transaction request itself. Instead, the payment details of the consumer included in the transaction request may be a proxy identifier. For example, the proxy identifier may be a primary account number of the consumer. The payer PSP may store details relating the proxy identifier of the consumer to underlying identifying details of the consumer, e.g., the government-controlled identifier. The intermediary party may request the government-controlled identifier of the consumer so as to identify previous payment transactions involving the consumer. The payment details of the merchant may comprise a proxy identifier for the merchant. A payee acquirer bank may maintain a relationship between the proxy identifier of the merchant and the government- controlled identifier of the merchant.

[0050] As above regarding the consumer, the government-controlled identifier of the merchant (e.g., tax code / number) may not be included in the transaction request itself. Instead, the payment details of the merchant included in the transaction request may be a proxy identifier. For example, the proxy identifier may be an acquirer ID, a merchant ID and / or a merchant name. The payee acquirer bank may store details relating the proxy identifier of the merchant to underlying identifying details of the merchant, e.g., the government-controlled identifier. The intermediary party may request the government-controlled identifier of the merchant so as to identify previous payment transactions involving the merchant.

[0051] The intermediary may be a payer payment service provider. If the determined fraud risk parameter does not exceed a predetermined threshold, generating the transaction output may comprise generating a payment authorisation request.

[0052] If it is determined that the new payment transaction is likely not fraudulent, the payer PSP may proceed with the transaction request in the normal way. For example, the payment authorisation request may be sent from the payer PSP to the payee’s issuer bank, so that the new transaction can be instigated.

[0053] The transaction output may comprise the fraud risk parameter. The method may further comprise sending, from the intermediary party of the payment system to a further party of the payment system, the transaction output. The intermediary party may be associated with the consumer and the further party may be associated with the merchant.

[0054] The transaction output, e.g., a payment authorisation request, may comprise the fraud risk parameter. Sharing of the determined fraud risk parameter may provide for increased transparency in the payment system. For example, where the fraud risk parameter is a percentage indicating the likelihood that the new payment transaction is fraudulent, and it is determined that the fraud risk parameter is sufficiently low, the fraud risk parameter may be shared with the issue and / or the acquirer as part of the payment authorisation request, so that both parties can verify that the new payment transaction is legitimate.

[0055] The computer implemented method may further comprise updating a database comprising existing card payment network details for merchants based upon the identified previous payment transactions conducted via the real time payment network involving the merchant.

[0056] The database comprising existing card payment network details for merchants may be the same database discussed above with regard to the onboarding process - e.g., the database may comprise a list of merchants that are restricted in using the card payment network. Where previous payment transactions conducted via the real time payment network involving the merchant are identified, and these previous payment transactions are determined to be fraudulent, the database comprising existing card payment network details for merchants may be updated accordingly. For example, a merchant may not appear on the list of merchants that are restricted in using the card payment network if their use of the card payment network is legitimate. However, if the same merchant has been conducting fraudulent or otherwise non-optimal transactions using the RTP network, the previous payment transactions conducted via the real time payment network involving the merchant that are identified may include fraudulent transactions. Thus, the list of merchants that are restricted in using the card payment network may be updated to include the merchant in question, as if they had conducted the fraudulent / non-optimal transactions on the card payment network itself. The present invention thus may provide for increased synchronisation / ecosystem management between the card payment network and the RTP network. Transactions that occur on the RTP network may be used to update databases / resources for the card payment network, and vice versa.

[0057] Updating the database comprising existing card payment network details for the merchant may comprise analysing the identified previous payment transactions conducted via the real time payment network involving the merchant to determine a reason parameter. The reason parameter may correspond to a reason why the merchant was added to the database comprising existing card payment network details. As discussed above with regard to the onboard process, the reason parameter may comprise one or more codes that indicate a behaviour of the merchant in past payment transactions. Analysing the identified previous payment transactions conducted via the real time payment network involving the merchant may comprise performing the same analysis as done when deciding whether to include merchant in the list of merchants that are restricted in using the card payment network. For example, the number of chargeback that the merchant has received in the a given month for payment transactions conducted on the RTP network and the monetary value of those chargebacks may be determined. If a predetermined threshold is met for these, an excessive chargeback reason parameter may be generated and the merchant included in the list of list of merchants that are restricted in using the card payment network.

[0058] The payment system may consist of a standalone real time payment network.

[0059] The payment system may be an A2A RTP network, for example an A2A RTP network that is operated by a central bank or other national financial institution. The payment transaction may be instigated by a consumer scanner a QR code associated with merchant and may be conducted by transferring funds directly from the consumer (payer) to the merchant (payee). However, despite being a standalone RTP network, the payment system may still make use of the databases / resources associated with the card payment network discussed herein. Therefore, subject to agreement between the relevant parties, identifiers of the merchant and / or consumer in the RTP network may be matched to corresponding identifiers in the card payment network. This may provide for improved governance of the two payment networks (e.g., by identifying merchants that are bad actors) and / or more accurate fraud detection and likelihood assessment.

[0060] The payment system may be a hybrid payment system comprising: the real time payment network configured to process payment transactions; and a card payment network configured to provide an interface between a payment card of the consumer and the real time payment network. Alternatively, the payment system may be a hybrid payment system. Payment transactions may still be processed via the RTP network, e.g., funds may still be transferred directly from the consumer (payer) to the merchant (payee), but may be initiated via the card payment network. For example, a consumer may use their debit card at a point-of-sale terminal, thereby instructing payment. But then, so long as both the consumer and merchant can use the RTP network, the card payment network may forward a request to the RTP network to continue with the payment transaction. In effect, the card payment network may be used to front the RTP network in the hybrid payment system. This may mean that users are provided with all of the benefits of using an RTP network (e.g., real time transfer of funds), while still be able to use familiar payment methods such as debit / credit cards.

[0061] According to another aspect of the invention, there is provided a system for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network. The system is configured to receive, at an intermediary party of the payment system, a request for a merchant to participate in the payment system, the request comprising identity details of the merchant. The system is further configured to compare the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details of the merchant in the database. The system is further configured to determine, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details of the merchant.

[0062] The system may be configured to perform a computer implemented method according to an aspect of the invention.

[0063] According to another aspect of the invention, there is provided a there is provided a non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to receive, at an intermediary party of the payment system, a request for a merchant to participate in the payment system, the request comprising identity details of the merchant. The instructions further cause the computer to compare the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details of the merchant in the database. The instructions further cause the computer to determine, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details of the merchant.

[0064] The non-transitory computer-readable medium may comprise instructions which, when executed by a computer, cause the computer to carry out a computer implemented method according to an aspect of the invention.

[0065] According to another aspect of the invention, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network. The method comprises receiving, at an intermediary party of the payment system, a request for a merchant to participate in the payment system, the request comprising identity details of the merchant. The method further comprises comparing the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details of the merchant in the database. The method further comprises determining, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details of the merchant.

[0066] The computer program product may comprise instructions which, when the program is executed by a computer, cause the computer to carry out the method according to an aspect of the invention.

[0067] According to another aspect of the invention, there is provided a system for processing a transaction request via a payment system, the payment system comprising a real time payment network. The system is configured to receive, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction. The system is further configured to compare payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network. The system is further configured to determine, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network. The system is further configured to generate, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

[0068] The system may be configured to perform a computer implemented method according to an aspect of the invention.

[0069] According to another aspect of the invention, there is provided a there is provided a non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to receive, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction. The instructions further cause the computer to compare payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network. The instructions further cause the computer to determine, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network. The instructions further cause the computer to generate, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

[0070] The non-transitory computer-readable medium may comprise instructions which, when executed by a computer, cause the computer to carry out a computer implemented method according to an aspect of the invention.

[0071] According to another aspect of the invention, there is provided a computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out a method for processing a transaction request via a payment system, the payment system comprising a real time payment network. The method comprises receiving, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction. The method further comprises comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network. The method further comprises determining, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network. The method further comprises generating, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

[0072] The computer program product may comprise instructions which, when the program is executed by a computer, cause the computer to carry out the method according to an aspect of the invention.

[0073] DESCRIPTION OF FIGURES

[0074] Embodiments of the invention will be described, purely by way of example, with reference to the accompanying drawings, in which:

[0075] Figure 1 shows a schematic diagram of an example standalone real time payment network;

[0076] Figure 2 shows a schematic diagram of an example of a hybrid payment network;

[0077] Figure 3 shows a schematic diagram of a method of controlling onboarding of merchants to a payment system comprising a real time payment network;

[0078] Figure 4 shows a schematic diagram of a method of processing a transaction request via a payment system comprising a real time payment network; Figure 5 shows a schematic diagram for a shared ecosystem governance scheme;

[0079] Figure 6 shows an example of a data processing device;

[0080] Figure 7 shows a flow diagram of a computer implemented method for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network; and

[0081] Figure 8 shows a flow diagram for a computer implemented method for processing a transaction request via a payment system, the payment system comprising a real time payment network.

[0082] DETAILED DESCRIPTION

[0083] Referring to Figure 1, a schematic diagram of an example standalone real time payment (RTP) network 100 is shown. The RTP network 100 may be any suitable RTP network - e.g., Pix - and can be used to transfer funds between parties directly and in near real time.

[0084] The consumer 102 initiates a purchase 104 from a merchant 106. The purchase 104 may be initiated using a mobile phone and an RTP network application by scanning a QR code in the merchant’s store, for example. Scanning the QR code may cause the consumer 102 to be provided with details of the merchant’s RTP network account 124, such as an account number / name. The consumer 102 may then send a transaction request 108 comprising payment details of the consumer 102 and the merchant 106, such as their respective RTP account details and a new payment transaction monetary amount.

[0085] The transaction request 108 may be received by a payer payment service provider (PSP) 110 that acts on behalf of the consumer 102 and processes at least some of their transaction requests 108. The payer PSP 110 may communicate 116 with a corresponding payee PSP 112 and / or a provider 114 of the RTP network. The RTP network provider 114 may be a central bank or other financial institution that controls / maintains the RTP network. Once the new payment transaction has been authorised, the payer PSP 110 may instruct 118 the payment, so that funds are transferred 120 from a consumer RTP account 122 to the merchant RTP account 124 via the RTP network. The communications 116 between the payer PSP 110, payee PSP 112 and the RTP network provider 114 may be dependent upon the RTP network that is utilised. Likewise, the communications to / from these parties may vary - e.g., the RTP network provider may send / coordinate the instruction 118 of the transfer of funds between the RTP accounts of the consumer and the merchant, rather than the payer PSP 110 as illustrated.

[0086] Referring to Figure 2, a schematic diagram of an example hybrid payment system 200 is shown. The hybrid payment system 200 can generally be understood to comprise a card payment network that is used to front an RTP network - the payment transaction is still processed using the RTP network (i.e., funds are sent between a consumer 202 and a merchant 206 using the RTP network), but the transaction is initiated using a conventional credit / debit card, for example.

[0087] The consumer 202 initiates a purchase 204 from a merchant 206 using a payment card. The merchant 206 sends a preliminary authorisation request 208 to an acquirer 210, who in turn sends a payment authorisation request 212 to an issuer 218. The payment authorisation request 212 may be sent via a card payment network provider 214, who forwards 216 the payment authorisation request to the issuer 218.

[0088] The consumer 202 and the merchant 206 may provide RTP network payment details as part of the transaction. For example, an account name / number for the consumer 202 and merchant 206 may be included in the payment authorisation request 216 received by the issuer. These may be included in an additional field of the request. Therefore, although the purchase 204 was conducted using a payment card, the transaction may be processed / settled using the associated RTP network. Alternatively, the consumer 202 and / or the merchant may not provide these RTP details, but instead they may be recalled by another party (e.g., the acquirer 210, payment network 214 or the issuer 218). For example, the issuer 218 may receive card payment / banking details in the payment authorisation request 216 and, based on these, look up linked RTP network details for the consumer and / or the merchant so that the transaction in question can be conducted using the RTP network. In this example of the hybrid payment system 200, it is the issuer 218 that instructs 219 the new payment transaction to be conducted using the RTP network; this is the point where the card payment network is linked to the RTP network so as to provide a hybrid system. However, this instruction 219 may instead be provided by another party, such as the acquirer 210 or a provider of the card payment network 214.

[0089] The issuer 218 sends instructions 219 for the new payment transaction to be performed via the RTP network. The instructions 219 may be sent to a provider of the RTP network and may comprise details identifying RTP accounts of the merchant 206 and the consumer 202 and an amount that is to be transferred.

[0090] The funds for the new payment transaction are taken from a consumer RTP account 222. The funds may be transferred directly 220a to a merchant RTP account 228a. Alternatively, RTP network details for the acquirer 210 may be provided on behalf of the merchant 206. In such instances, the funds may be transferred 220b to an acquirer RTP account 224a. The funds may then be forwarded to the merchant 206, either via a further RTP transfer 226a to the merchant RTP account 228 or via a transfer 226 to a merchant bank account 228b using, for example, a conventional bank transfer.

[0091] Referring to Figure 3, a schematic diagram of a method 300 of controlling onboarding of merchants to a payment system comprising an RTP network is shown. A merchant 302 provides a request 310 to participate in the payment system. The request 310 may be generated by the merchant completing a sign-up process for joining the payment system, e.g., following a sign-up web link and / or submitting details via a web form.

[0092] The request 310 comprises identity details 312 of the merchant. The identity details 312 of the merchant 302 may comprise a merchant name, a merchant address, a merchant tax code / ID, and / or details of any principles acting on behalf of the merchant, for example. The merchant 302 may be prompted to submit said details when completing the sign-up process, thereby providing the identity details 312 as part of the participation request 310.

[0093] The participation request 310 is received by an intermediary party 304. Upon receiving the participation request 310, the intermediary party 304 compares the identity details 312 of the merchant to a database 320 of existing card payment network details. The database 320 comprises information regarding previous payment transactions that have been conducted via a card payment network (i.e., convention payments that have been facilitated using debit / credit cards, for example).

[0094] The database 320 may comprise a list of merchants that have been deemed to be bad actors based upon previous payment transactions that they have been involved in on the card payment network. Merchants may be placed onto the list if they activate a reason code relating to their previous payment transactions, where the conditions for activating the reason code being determined by a provider of the card payment network. For example, a merchant may be placed onto the list of bad actors if they are deemed to have been involved in excessive chargebacks - e.g., the number of chargebacks for payment transactions on the card payment network in any single month exceeded 1% of the number of payment transactions in that month, and those chargebacks totalled USD 5,000. The database 320 may be used to impose restrictions on the bad actor merchants, e.g., the listed merchants may be unable to use the card payment network.

[0095] During the onboarding process, the intermediary party 304 compares the identity details 312 to the database 320 of existing card payment network details. The comparison may comprise querying the database 320 with one or more components of the identity details 312 provided in the participation request 310. For example, the intermediary party 304 may search the database 320 for a merchant name or a merchant tax ID. The comparison may comprise directly calling an application programming interface (API) for the database 320 and providing the identity details 312 of the merchant.

[0096] In doing so, existing card payment network details for the merchant 322 in the database 320 may be identified. I.e., if the merchant 302 has been included in the list of bad actors that is the database 320, searching for said merchant 302 using the identity details 312 provided in the request 310 may identify their entry in the list, thereby determining that the merchant in questions is considered to be a bad actor based upon previous payment transactions conducted via the card payment network. For example, an example of a request for adding a merchant to the list of bad actor merchants that is the database 320 is shown below:

[0097] {

[0098] "AddMerchantRequest": {

[0099] "Acquirerld": "1996",

[0100] "Merchant": {

[0101] "Name": "THE BAIT SHOP",

[0102] "DoingBusinessAsName": "BAIT R US",

[0103] "Merchantld": "1234567890",

[0104] "MerchantCategory": "0742",

[0105] "Address": {

[0106] "Linel”: ”42 ELM AVENUE”,

[0107] "Line2": "SUITE 201",

[0108] "City": "DALLAS",

[0109] "CountrySubdivision": "IL",

[0110] "Province": "US",

[0111] "PostalCode": "66579",

[0112] "Country": "USA"

[0113] "PhoneNumber": "6367558963",

[0114] " AltPhoneNumber": "6367558968",

[0115] "NationalTaxId": "*****",

[0116] " Country SubdivisionTaxId" : "*****",

[0117] "CATFlag": "Y",

[0118] "DateOpened": "12 / 31 / 2013",

[0119] "DateClosed": "10 / 12 / 2014",

[0120] "ServiceProvLegal": "XYZ FINANCIAL SERVICE

[0121] INCORPORATED",

[0122] "ServiceProvDBA": "XYZ FINANCIAL SERVICE",

[0123] "Url": [

[0124] "www.testmerchant.com"

[0125] ],

[0126] "Principal": [

[0127] { "FirstName": "DAVID",

[0128] "Middlelnitial" : "P",

[0129] "LastName" : "SMITH", "Address" : {

[0130] "Linel" : "42 ELM AVENUE",

[0131] "Line2" : "SUITE 201",

[0132] "City": "DALLAS",

[0133] "Country Subdivision": "IL",

[0134] "Province" : "US", "PostalCode": "66579", "Country": "USA"

[0135] "PhoneNumber": "3165557625",

[0136] " AltPhoneNumber" : "3165557625", "Nationalld": "541022104", "DriversLicense": {

[0137] "Number": "M15698025",

[0138] "Country Subdivision": "IL", "Country": "USA"

[0139] }

[0140] }

[0141] ],

[0142] "ReasonCode" : " 13",

[0143] "Comments" : "Added for reasons of fraud"

[0144] }

[0145] }

[0146] }

[0147] As shown above, fields that are provided for the bad actor merchant for including in the list include a number of different details / identifiers. Details include various names of the merchant, contact details (e.g., an address and phone numbers) and a national tax ID. In this instance, the details include details for a principal - the principal may be an entity that acts on behalf of the merchant, for example a particular store that operates for a company. If the identity details 312 included in the participation request 310 correspond to any of the fields of the database 320 that are queried, existing card payment network details for the merchant 322 in the database 320 may be identified. Based upon this, the intermediary party 304 may determine that the merchant 302 should not be onboarded to the payment system. Alternatively, if no such existing card payment network details for the merchant 322 are identified in the database 320 - i.e., the merchant 302 is not included in the list of bad actor merchants - the intermediary party 304 may determine that the merchant 302 is suitable for onboarding to the payment system.

[0148] If it is determined that the merchant 302 can be onboarded to the payment system, the intermediary party 304 may generate RTP network details 330 for the merchant. Using the RTP network detail 330, the merchant 302 may then participate in the payment system; they may conduct payment transactions that utilise the RTP network.

[0149] The database 320 may include a reason parameter corresponding to why the merchant 302 was included in the list of bad actors. A reason parameter is provided in the example above - “"ReasonCode" : " 13", "Comments": "Added for reasons of fraud"”. The intermediary party 304 may retrieve the reason parameter when comparing the identity details 312 of the merchant to the database 320. The reason parameter may be utilised by the intermediary party 304 when deciding whether to onboard the merchant 302.

[0150] Referring to Figure 4, a schematic diagram of a method 400 of processing a transaction request via a payment system comprising an RTP network is shown. A payment transaction is initiated by a transaction request 410, the transaction request 410 comprising payment details for the merchant 412 and payment details for the consumer 414.

[0151] The generation of transaction request 410 may depend upon the type of payment system in question. For example, if the payment system is a standalone RTP network, then the transaction request 410 may be initiated by a consumer scanning a QR with a mobile phone equipped with a mobile phone application for the RTP network. In this case, the transaction request may be generated by a payee payment service provide (PSP) 402 associated with the RTP network. Alternatively, the payment system may be a hybrid payment system comprising an RTP network and a card payment network. In this case, the transaction request may be initiated by a consumer providing a debit / credit card to a point-of-sale terminal. A preliminary transaction request (not shown) may be generated by the merchant at the point-of-sale terminal and sent to their acquirer bank 402. The acquirer 402 may then generate the transaction request 410. But in either case, the method 400 comprises the transaction request 410 being provided to an intermediary party 404.

[0152] Upon receiving the transaction request 410, the intermediary party 404 compares the payment details of the merchant 412 and the payment details of the consumer 414 a database 420a of previous payment transactions conducted via a card payment network. The database 420a may comprise a list of previous payment transactions conducted via the card payment network that are known to be fraudulent. For example, these transactions may have been reported by parties of the card payment network (e.g., by an issuer bank of a payer) as being fraudulent. The database 420a may be used by a provider of the card payment network itself in order to provide fraud detection. Models (e.g., Al-based fraud detection models) may be trained on the list of known fraudulent transactions, so as to develop algorithms for detecting fraud.

[0153] For example, an example of a transaction stored in the database 420a is shown below:

[0154] {

[0155] "refld": "ecb2d942-eabd-42b6-87fd-69cl9692bdc6", "timestamp" : "2021-03-16T20:34:37-06:00", "icaNumber" : " 1076",

[0156] "auditControlNumber" : " 123111111000025 ", "acquirerld": "2742", "cardNumber" : "5587450000000008074", "fraudTypeCode" : "01", "fraudSubTypeCode" : "U", "cardProductCode": "CIR", "transact! onDate" : "20200215", "settlementDate" : "20200216", "fraudPostedDate": "20210316", "cardholderReportedDate": "20210314", "transact! onAmount" : "56823 ", "transactionCurrencyCode" : "840", "billing Amount": "56823", "billingCurrencyCode" : "840", "merchantld": "6698696", "merchantName" : "B ANKNEWPORT", "merchantCity" : "Phoenix", "merchantStateProvinceCode": "AZ", "merchantCountryCode" : "USA", "merchantPostalCode": "85001 ", "merchantCategoryCode": "6011", "terminalAttendancelndicator" : "0", "terminalld": "5055D305", "terminalOperatingEnvironment" : " 1 ", "cardholderPresencelndicator" : "0", "cardPresencelndicator" : " 1 ", "cardlnPossession": "Y", "catLevellndicator" : "2", "terminalCapabilitylndicator": "0", "posEntryMode" : "00", "cvclnvalidlndicator": "M", "avsResponseCode" : "U", "authResponseCode": "00", "secureCode" : "9", "accountDeviceType": "A", "transactionindicator" : "M205", "memo": "This is a sample FDC complete request.", "issuerSCAExemption" : "09" } As shown above, the stored transaction comprises a number of fields that contain many different details / identifiers. Details include an acquirer ID, a card number (i.e., the consumer card that was used in the transaction) and details of the merchant (name, ID, address). If the payment details of the merchant 412 and / or the payment details of the consumer 414 correspond to any of the fields of the database 420a that are queried, previous payment transactions 422a conducted via the card payment network may be identified. Based upon the comparison of the payment details of the merchant 412 and / or the payment details of the consumer 414 to the database 420a of previous payment transactions conducted via the card payment network, the intermediary party 404 determines a fraud risk parameter. The fraud risk parameter describes a likelihood that the new payment transaction that is being instructed by the transaction request 410 is fraudulent, based on this comparison.

[0157] For example, when the database 420a is queried using information from the payment details of the merchant 412 and the payment details of the consumer 414, a large number of previous payment transactions 422a conducted via the card payment network involving the merchant and / or the consumer may be identified. This may indicate that merchant and / or consumer has been involved in many transactions that have been reported as fraudulent. This may result in a high fraud risk parameter. Alternatively, if no, very few (e.g., less than 5), or no recent (e.g., occurring in the last 6 months) previous payment transactions 422a are identified, this may indicate that the merchant and consumer are not likely to be involved in fraudulent transactions. This may result in a low fraud risk parameter. The fraud risk parameter may be a numerical score, for example the total number of previous payment transactions 422a identified in the database 420a. Alternatively, the fraud risk parameter may be a percentage indicating the likelihood that the transaction request 410 is for a fraudulent payment transaction.

[0158] In addition to utilising the database of database 420a of previous payment transactions conducted via a card payment network, the intermediary party 404 may similarly utilise a database 420b of previous payment transactions conducted via the real time payment network. Similarly, to above, the database 420b may comprise a list of previous payment transactions conducted via the RTP network that are known to be fraudulent. The database 420b may be used by a provider of the RTP network for their own fraud detection purposes. The intermediary party 404 may likewise compare the payment details of the merchant 412 and the payment details of the consumer 414 a database 420b of previous payment transactions conducted via a RTP network. If the payment details of the merchant 412 and / or the payment details of the consumer 414 correspond to any of the fields of the database 420b that are queried, previous payment transactions 422b conducted via the RTP network involving the merchant and / or the consumer may be identified. The fraud risk parameter may be based also on the results of this additional comparison - if many previous payment transactions 422b are identified, this may indicate that the merchant and / or consumer have been involved in many fraudulent transactions, and vice versa.

[0159] The identified previous payment transactions conducted via the card payment network 422a may be previous transactions that involve the merchant and / or the consumer, and may be found by querying database 420a using the payment details of the merchant 412 and / or the payment details of the consumer 414, as discussed above. However, previous payment transactions may also / instead be identified that do not directly involve the merchant or consumer. A machine learning engine may be trained to analyse the database 420a so as to identify data patterns, thereby enabling links to be found between the merchant / consumer payment details 412, 414 and the database 420a. For example, a fraudulent party may have captured an account and used this as for the new payment transaction, such that the new account is ‘clean’ and so not associated with a consumer / merchant found in the database of previous card payment transactions 420a. Nonetheless, previous card payment transactions may still be identified using the machine learning engine based on predicted behaviours and other information contained in the transaction request 410 and / or the database 420a - e.g., a card type, details of the transaction such as amount or the type of goods / services, and / or a recurrence pattern of transactions.

[0160] The same may also be true for the identification of previous RTP network transactions 422b from the database 420b of previous payment transactions conducted via the real time payment network; the identified transaction(s) 422b may not explicitly involve the merchant or the consumer. The machine learning engines may be developed and controlled by a third party, for example the providers of the card payment network and the RTP network.

[0161] Based upon the determined fraud risk parameter, the intermediary 404 generates a transaction output 430. Where the fraud risk parameter exceeds a predetermined threshold (i.e., the likelihood that the new payment transaction is fraudulent is too high), the transaction output 430 may comprise instructions to terminate the new payment transaction. The transaction request 410 may be requested, and no funds taken form the consumer. A message may be provided to any of the parties involved in the payment system to inform them that the new payment transaction has been terminated. Alternatively, if the fraud risk parameter does not exceed the predetermined threshold (i.e., the likelihood that the new payment transaction is fraudulent is sufficiently low), the new payment transaction may be proceeded with. The transaction output 430 may comprise a payment authorisation request so that the transaction can be completed. The transaction output 430 may comprise the payment details for the merchant 412 and the payment details for the consumer 414, so that funds can be transferred between the two via the RTP network.

[0162] Referring to Figure 5, a schematic diagram of a scheme 500 for providing shared governance between a card payment network and a real time payment (RTP) network is shown. The scheme 500 may use the methods described herein to analyse / update databases and other resources associated with the card payment network and the RTP network, thereby enabling a payment ecosystem that may be more easily synchronised.

[0163] A consumer 502 communicates 504a with a payer-side entities 507a that may be involved in a payment network (e.g., a standalone RTP network like Figure 1, or a hybrid payment network like Figure 2). The payerside entities 507a may comprise an issuing bank 509 for the consumer 502 and / or a payer payment service provider (PSP) 510, for example. Likewise, a merchant 506 communicates 504b with payee-side entities 507b that may be involved in the payment network. The payee-side entities 507b may comprise an acquirer financial institution 511 for the merchant and payee PSP 512, for example. The communication 504a may correspond to a transaction request for the consumer 502 to engage in a new payment transaction, for example. The communication 504b from the merchant 506 may correspond to an onboarding request for merchant 506 to be able to use RTP network. The transaction request and the onboard request may be processed using the methods / systems discussed herein. As part of these processes, the payer-side entities 507a may communicate with a provider 514 of the RTP network and the payee-side entities 507b may communicate 508b with the RTP network provider 514. The payer and payee-side entities 507a, 507b may also communicate with one another to enable these processes.

[0164] As discussed herein, various resources may be used to improve the security / resilience of these transaction and onboarding methods. A card payment network provider may control a database 520 of previous payment transactions conducted via a card payment network and / or a database 524 comprising existing card payment network details. The RTP network provider 514 may control a database 522 of previous payment transactions conducted via the RTP network.

[0165] For example, during an onboarding process for the merchant 506, identity details for the merchant 506 provided in an onboarding request may be compared 534 to the database 524 comprising existing card payment network details. The database 524 may comprise a list of known ‘bad actor’ merchants, meaning that if the merchant’s identity details appear in the database 524 the merchant 506 may be prevented from being onboarded to the payment network. In another example, during a new payment transaction, payment details of the consumer 502 and / or of the merchant 506 provided in a transaction request may be compared 530 to the database 520 of previous payment transactions conducted via the card payment network, and / or may be compared 532 to the database 522 of previous payment transactions conducted via the RTP network. The databases of previous transactions 520, 522 may comprise a list of known-fraudulent transactions (that may have been identified / collated using a machine learning engine), meaning that if consumer and / or merchant’s payment details appear in these databases the new payment transaction may be rejected on the grounds that it may be fraudulent, for example. As part of these processes, the various databases discussed may be updated and synchronised, which can improve the reliability and robustness of security / anti-fraud methods utilised on both the card payment network and the RTP network. The_database 520 of previous payment transactions conducted via the card payment network and the database 522 of previous payment transactions conducted via the RTP network may be updated 536 based upon one another.

[0166] For example, if a potentially fraudulent transaction is identified for the consumer / merchant in the card payment network database 520, the RTP network database 522 may be updated to include details of this potentially fraudulent transaction, and vice versa. Both databases 520, 522 may be updated to include details for the new payment transaction if it is found to be potentially fraudulent. Thus, the databases 520, 522 may be supplemented with additional data as a result of the methods described herein.

[0167] In another example, a fraudulent merchant 506 may be identified during an onboarding process or a new payment transaction by comparing / analysing the database 522 of previous payment transactions conducted via the RTP network. The database 524 comprising existing card payment network details may be updated to include the identified details of the merchant 506. Thus, the list of known ‘bad actors’ may be supplemented by using data from the RTP network, which may enable troublesome merchants to be identified who could not otherwise be identified based on card payment network data alone.

[0168] It will be appreciated that any of the methods described herein, and any step of the methods, can be implemented by a computer. Such implementation may take the form of a processor executing instructions stored on a non-transitory computer-readable medium or media, wherein when executed the instructions cause the processor to perform any one or more steps of any of the methods described herein. Individual steps of any method may be implemented by different processors that are all collectively acting in accordance with computer-readable instructions stored on one or more storage media. The processor(s) may be component(s) of system, for example a processor of a device. Similarly, any steps of any of the methods described herein may be performed by data processing devices. By way of example, Figure 6 shows, in schematic form, a data processing device 600 that is suitable for controlling onboarding of merchants to a payment system and / or processing a transaction request, or any of the steps / processes therein. The data processing device 600 may automatically perform any of the methods described herein.

[0169] One or more such data processing devices 600 may be provided for implementing the method of the present invention. For example, each of a consumer device (e.g., a mobile phone), a merchant device (e.g., a point-of- sale terminal), and a device associated with an intermediary party (e.g., an issuer, an acquirer, a RTP network provider, a card payment network provider and / or a PSP) may comprise a data processing device 600. Distinct data processing devices 600 may be used for various steps / processes of the method described herein. Said devices may be networked together appropriately to enable any of the methods described herein.

[0170] Data processing device 600 includes a processor 603 for executing instructions. Instructions may be stored in a memory 601. Processor 603 may include one or more processing units (e.g., in a multi-core configuration) for executing instructions. The instructions may be executed within a variety of different operating systems on the data processing device 600, such as UNIX, LINUX, Microsoft Windows®, etc. More specifically, the instructions may cause various data manipulations on data stored in memory 601 (e.g., create, read, update, and delete procedures). It should also be appreciated that upon initiation of a computer-implemented method, various instructions may be executed during initialization. Some operations may be required to perform one or more methods described herein, while other operations may be more general and / or specific to a particular programming language (e.g., C, C#, C++, Java, or other suitable programming languages, etc.).

[0171] Processor 603 is operatively coupled to a communication interface 605 such that data processing device 600 can communicate with a remote device, such as another data processing device of the system. For example, communication interface 605 may receive communications from another member of the system. Processor 603 may also be communicatively coupled to a storage device such as a database, depending on the function of data processing device 600 within the context of the system. The storage device is any computer-operated hardware suitable for storing and / or retrieving data, where in the case of a secure storage medium the data is stored and retrieved securely.

[0172] The storage database may, for example, store the onboard request, the transaction request and / or the various databases discussed herein (and any data / information contained therein), and it can be external to data processing device 600 and located remotely. Alternatively, it can be integrated in data processing device 600. For example, data processing device 600 may include memory 601 as one or more hard disk drives acting as a storage database. Alternatively, where the storage database is external to data processing device 600, it can comprise multiple storage units such as hard disks or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The storage database may include a storage area network (SAN) and / or a network attached storage (NAS) system. In some arrangements, the system and methods may be deployed in a cloud-based environment.

[0173] Processor 603 can be operatively coupled to the storage device (storage database) via a storage interface 607. Storage interface 607 is any component capable of providing processor 603 with access to the storage device. Storage interface 607 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and / or any component providing processor 603 with access to the storage device.

[0174] Memory 601 may include, but is not limited to, RAM such as dynamic RAM (DRAM) or static RAM (SRAM), ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and non-volatile RAM (NVRAM). The above memory types are exemplary only and are not limiting as to the types of memory usable for storage of a computer program. As used herein, the term "non-transitory computer-readable media / medium" is intended to be representative of any tangible computer- based device implemented in any method or technology for short-term and long-term storage of information, such as, computer-readable instructions, data structures, program modules and sub-modules, or other data in any device. The methods described herein may be encoded as executable instructions embodied in a tangible, non-transitory, computer readable medium, including, without limitation, a storage device, and / or a memory device. Such instructions, when executed by a processor, cause the processor to perform at least a portion of the methods described herein. Furthermore, as used herein, the term "non-transitory computer-readable media / medium" includes all tangible, computer-readable media, including, without limitation, non-transitory computer storage devices, including, without limitation, volatile and non-volatile media, and removable and non-removable media such as a firmware, physical and virtual storage, CD-ROMs, DVDs, and any other digital source such as a network or the Internet, as well as yet to be developed digital means, with the sole exception being a transitory, propagating signal.

[0175] As will be appreciated based on the specification herein, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof. Any such resulting program, having computer-readable code means, may be embodied, or provided within one or more computer-readable media, thereby making a computer program product, i.e., an article of manufacture, according to the discussed embodiments of the disclosure. The article of manufacture containing the computer code may be made and / or used by executing the code directly from one medium, by copying the code from one medium to another medium, or by transmitting the code over a network.

[0176] While the disclosure has been described in terms of various embodiments, the person skilled in the art will recognise that the disclosure can be practiced with modification within the spirit and scope of the claims.

[0177] Referring to Figure 7, a flow diagram 700 of a computer implemented method for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network, is shown. Said method may be performed by the entities / payment networks described above.

[0178] At step 702, the method involves receiving, at an intermediary party of the payment system, a request for a merchant to participate in the payment system, the request comprising identity details of the merchant.

[0179] At step 704, the method involves comparing the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details of the merchant in the database.

[0180] At step 706, the method involves determining, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details of the merchant.

[0181] Referring to Figure 8, a flow diagram 800 of a computer implemented method processing a transaction request via a payment system, the payment system comprising a real time payment network, is shown. Said method may be performed by the entities / payment networks described above.

[0182] At step 802, the method involves receiving, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction.

[0183] At step 804, the method involves comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network.

[0184] At step 806, the method involves determining, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network.

[0185] At step 808, the method involves generating, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

Claims

CLAIMS1. A computer implemented method for controlling onboarding of merchants to a payment system, the payment system comprising a real time payment network, the method comprising: receiving, at an intermediary party of the payment system, a request for a merchant to participate in the payment system, the request comprising identity details of the merchant; comparing the identity details of the merchant to a database comprising existing card payment network details to identify existing card payment network details of the merchant in the database; and determining, at the intermediary party of the payment system, whether the merchant should be onboarded to the payment system based upon the identified existing card payment network details of the merchant.

2. The computer implemented method of claim 1, wherein the database comprises previous transaction information for past payment transactions involving the merchant conducted via the card payment network; and wherein comparing the identity details of the merchant to the database comprises identifying past payment transactions involving the merchant that resulted in a non-optimal transaction outcome.

3. The computer implemented method of claim 1 or claim 2, wherein the database comprises existing card payment network details for merchants that have been determined to be high risk based on past payment transactions, wherein the database comprises a reason parameter, the reason parameter corresponding to a reason why each merchant was included in the database; and wherein comparing the identity details of the merchant to the database comprises retrieving the reason parameter.

4. The computer implemented method of any preceding claim, wherein the database comprises existing card payment network details for one or more principals acting on behalf of the merchant, and wherein the identity details of the merchant comprise identity details of one of said principals; and wherein determining whether the merchant should be onboarded to the payment system comprises: determining whether the principal whose identity details are contained in the request should be onboarded to the payment system; or determining whether the merchant and each principal should be onboarded to the payment system.

5. The computer implemented method of any preceding claim, wherein the identity details of the merchant comprises a government- controlled identifier; and wherein identifying the existing card payment network details for the merchant is based at least in part on the government-controlled identifier.

6. The computer implemented method of any preceding claim, wherein the intermediary party is a payee payment service provider; and determining whether the merchant should be onboarded to the payment system comprises determining whether the payee payment service provider should allow the merchant to be involved in future payment transactions to be conducted at least in part via the real time payment network.

7. The computer implemented method of any of claims 1 to 5, wherein the intermediary party is a custodian of the real time payment network; and determining whether the merchant should be onboarded to the payment system comprises determining whether the identity details of the merchant should be stored.

8. The computer implemented method of any preceding claim, further comprising, if it is determined that the merchant should be onboarded to the payment system, generating a proxy identity for the merchant associated with the real time payment network.

9. A computer implemented method of processing a transaction request via a payment system, the payment system comprising a real time payment network, the method comprising: receiving, at an intermediary party of the payment system, a transaction request, the transaction request comprising payment details of a consumer and a merchant involved in a new payment transaction; comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via a card payment network to identify a previous payment transaction conducted via a card payment network; determining, at the intermediary party of the payment system, a fraud risk parameter related to the likelihood that the new payment transaction is fraudulent based on the identified previous payment transactions conducted via the card payment network; and generating, at the intermediary party of the payment system, a transaction output comprising details for how to proceed with the new payment transaction, the transaction output based on the determined fraud risk parameter.

10. The computer implemented method of claim 9, wherein, if the determined fraud risk parameter exceeds a predetermined threshold, the transaction output comprises instructions to terminate the new payment transaction.

11. The computer implemented method of claim 10, further comprising comparing payment details of the consumer and / or the merchant to a database of previous payment transactions conducted via the real time payment network to identify previous payment transaction conducted via the real time payment network,wherein the fraud risk parameter is also based on the identified previous payment transactions conducted via the real time payment network.

12. The computer implemented method of claim 11, further comprising: updating the database of previous payment transactions conducted via the real time payment network to include the identified previous payment transactions conducted via the card payment network; and / or updating the database of previous payment transactions conducted via the card payment network to include the identified previous payment transactions conducted via the real time payment network.

13. The computer implemented method of any of claim 11 or claim 12, wherein the database of previous payment transactions conducted via the real time payment network and / or the database of previous payment transactions conducted via the card payment network comprise a government- controlled identifier for the merchant and / or the consumer.

14. The computer implemented method of claim 13, wherein the payment details of the consumer comprise a proxy identifier for the consumer, and wherein a payer payment service provider maintains a relationship between the proxy identifier of the consumer and the government-controlled identifier of the consumer.

15. The computer implemented method of claim 13 or 14, wherein the payment details of the merchant comprise a proxy identifier for the merchant, and wherein a payee acquirer bank maintains a relationship between the proxy identifier of the merchant and the government-controlled identifier of the merchant.

16. The computer implemented method of any of claims 9 to 15, wherein the intermediary is a payer payment service provider; andwherein, if the determined fraud risk parameter does not exceed a predetermined threshold, generating the transaction output comprises generating a payment authorisation request.

17. The computer implemented method of any of claims 9 to16, wherein the transaction output comprises the fraud risk parameter, the method further comprising: sending, from the intermediary party of the payment system to a further party of the payment system, the transaction output, wherein the intermediary party is associated with the consumer and the further party is associated with the merchant.

18. The computer implemented method of any of claims 11 to17, further comprising updating a database comprising existing card payment network details for the merchant based upon identified previous payment transactions conducted via the real time payment network involving the merchant.

19. The computer implemented method of claim 18, wherein updating the database comprising existing card payment network details for the merchant comprises analysing the identified previous payment transactions conducted via the real time payment network involving the merchant to determine a reason parameter, wherein the reason parameter corresponds to a reason why the merchant was added to the database comprising existing card payment network details.

20. The computer implemented method of any preceding claim, wherein the payment system consists of a standalone real time payment network.

21. The computer implemented method of any of claims 1 to 19, wherein the payment system is a hybrid payment system comprising: the real time payment network configured to process payment transactions; anda card payment network configured to provide an interface between a payment card of the consumer and the real time payment network.

22. A system for controlling onboarding of merchants to a payment system, wherein the system is configured to perform the method of any of claims 1 to 8.

23. A system for processing a transaction request via a payment system, wherein the system is configured to perform the method of any of claims 9 to 21.

24. A non-transitory computer-readable medium comprising instructions which, when executed by a computer, cause the computer to carry out the method of any claim 1 to 21.

25. A computer program product comprising instructions which, when the program is executed by a computer, cause the computer to carry out the method of any of claims 1 to 21.

Images