Flexible transaction processing

CN123023075APending Publication Date: 2026-10-30VISA INTERNATIONAL SERVICE ASSOCIATION
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202580023471.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Priority Date
2024-03-25
Filing Date
2025-03-25
Publication Date
2026-10-30

AI Technical Summary

Technical Problem

[0006]另外,用户用于选择来源的过程是低效的,因为该过程将每次做出最佳选择的负担加在用户身上,而不具有对完整信息集合的访问权限,并且在结账时作出决策的时间窗口较短

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN123023075A_ABST
    Figure CN123023075A_ABST
Patent Text Reader

Abstract

A server computer can receive an authorization request message from a resource provider computer operated by a resource provider, the authorization request message including a flexible credential and an amount for a transaction conducted between a user and the resource provider. The flexible credential can be associated with a plurality of sources. The server computer can then determine a subset of user rules, of a set of user rules associated with the flexible credential, to apply to the transaction. The server computer can determine a subset of resource provider rules of resource provider rules of the resource provider based on the subset of user rules to apply to the transaction. The server computer can then apply the subset of user rules and the subset of resource provider rules to the transaction.
Need to check novelty before this filing date? Find Prior Art

Description

[0001] Cross-references to related applications

[0002] This application is a non-provisional application and claims the benefit of U.S. Provisional Patent Application No. 63 / 569,597, filed March 25, 2024, which is incorporated herein by reference in its entirety. Background Technology

[0003] Transaction processing networks rely on Bank Identification Numbers (BINs) to identify card issuers and route transactions to the appropriate network for processing. BINs are classified as binary because they identify specific types of card products. In recent years, alternative methods for funding transactions have emerged, such as using loyalty points for payments or utilizing short-term loans.

[0004] From a technical processing perspective, existing solutions that allow user choice are inefficient and require either: 1) a two-message approach for the network and ecosystem, where a pre-authorization message is used to check the appropriate source, followed by an authorization message for the actual transaction processing. This approach nearly doubles the amount of real-time messaging currently required to support purchases, demanding significantly higher bandwidth and capacity while increasing latency; and 2) providing consumers with multiple payment credentials (e.g., accounts associated with physical cards), which is costly (e.g., requiring the physical creation, mailing, and updating of multiple credentials, as well as the associated work of issuing multiple digital credentials) and increases fraud and authentication computation workload within the network (e.g., multiple credentials are more likely to be lost or stolen).

[0005] Furthermore, each time a new source is introduced, the current BIN-based payment network architecture generates considerable network and ecosystem development work, as these new sources are hard-coded into the credential type.

[0006] Furthermore, the process by which users choose a source is inefficient because it places the burden of making the best choice each time on the user, without access to the complete set of information, and the time window for making a decision at checkout is short.

[0007] The implementation scheme disclosed herein addresses these and other issues individually and collectively. Summary of the Invention

[0008] One implementation relates to a method comprising: receiving, by a server computer, an authorization request message from a resource provider computer operated by a resource provider, the authorization request message including a flexible credential and an amount for a transaction between a user and a resource provider, the flexible credential being associated with multiple sources; determining, by the server computer, a subset of user rules from a set of user rules associated with the flexible credential to be applied to the transaction; determining, by the server computer, a subset of resource provider rules of the resource provider based on the subset of user rules to be applied to the transaction; and applying the subset of user rules and the subset of resource provider rules to the transaction by the server computer.

[0009] Another embodiment relates to a server computer, including: a processor; and a computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: receiving an authorization request message from a resource provider computer operated by a resource provider, the authorization request message including a flexible credential and an amount for a transaction between a user and a resource provider, the flexible credential being associated with multiple sources; determining a subset of user rules from a set of user rules associated with the flexible credential to be applied to the transaction; determining a subset of resource provider rules of the resource provider based on the subset of user rules to be applied to the transaction; and applying the subset of user rules and the subset of resource provider rules to the transaction.

[0010] Another implementation relates to a method comprising: receiving, by a resource provider computer, a flexible credential for a transaction between a user and a resource provider from a user equipment, wherein the resource provider computer is operated by the resource provider and wherein the flexible credential is associated with multiple sources; identifying, by the resource provider computer, the flexible credential as associated with the multiple sources using an identification table; determining, by the resource provider computer, one or more resource provider rules for the transaction; generating, by the resource provider computer, an authorization request message for the transaction, wherein the authorization request message includes the flexible credential and an amount; and providing the authorization request message and one or more resource provider rules to a transmitting computer to request authorization for the transaction.

[0011] Further details regarding embodiments of this disclosure can be found in the detailed description and accompanying drawings. Attached Figure Description

[0012] Figure 1 A block diagram of the system according to the implementation scheme is shown.

[0013] Figure 2 A block diagram of components of a transmission computer according to an example implementation scheme is shown.

[0014] Figure 3A block diagram of the components of an example network processing computer according to an implementation scheme is shown.

[0015] Figure 4 A flowchart illustrating the determination of interactive processing methods based on rules of a network-based processing computer according to the implementation scheme is shown.

[0016] Figure 5 A flowchart illustrating an interactive processing method including an alternative network processing computer according to an implementation scheme is shown. Detailed Implementation

[0017] Before discussing the implementation schemes of this disclosure, some terms may be described in further detail.

[0018] "User" can include an individual. In some implementations, a user can be associated with one or more personal accounts and / or mobile devices. In some implementations, a user may also be referred to as a cardholder, account holder, or consumer.

[0019] "User equipment" can be a device operated by a user. Examples of user equipment can include mobile phones, smartphones, cards, personal digital assistants (PDAs), laptops, desktop computers, server computers, vehicles (e.g., automobiles), simplified client devices, tablet PCs, and so on. Additionally, user equipment can be any type of wearable technology device, such as watches, headphones, glasses, etc. User equipment can include one or more processors capable of processing user input. User equipment can also include one or more input sensors for receiving user input. As is known in the art, various input sensors capable of detecting user input exist, such as accelerometers, cameras, microphones, etc. User input obtained by input sensors can come from various data input types, including but not limited to audio data, visual data, or biometric data. User equipment can include any electronic device that can be operated by a user, which can also provide remote communication capabilities with a network. Examples of remote communication capabilities include using mobile phone (wireless) networks, wireless data networks (e.g., 3G, 4G, or similar networks), Wi-Fi, Wi-Max, or any other communication medium that can provide access to a network (e.g., the Internet or a private network).

[0020] An "access device" can be any suitable device that provides access to a remote system. Access devices can also be used to communicate with a coordinating computer, communication network, or any other suitable system. Access devices can typically be located anywhere suitable, such as at the merchant's location. Access devices can take any suitable form. Some examples of access devices include POS or point-of-sale devices (e.g., POS terminals), cellular phones, personal digital assistants (PDAs), personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), vending machines, automatic teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, etc.

[0021] Access devices can use any suitable contact or contactless operating mode to send or receive data from or associated with mobile communication devices or payment devices. For example, an access device may have a card reader that may include electrical contacts, radio frequency (RF) antennas, optical scanners, barcode readers, or magnetic stripe readers to interact with portable devices such as payment cards.

[0022] A "resource provider" can be an entity that can provide resources such as goods, services, information, and / or access. Examples of resource providers include merchants, data providers, transportation departments, government entities, venue and residential operators, etc.

[0023] "Interaction" can include mutual interaction or influence. "Interaction" can include communication, contact, or exchange between parties, devices, and / or entities. Example interactions include transactions between two parties and data exchange between two devices. In some embodiments, interaction can include a user requesting access to secure data, secure web pages, secure locations, etc. In other embodiments, interaction can include payment transactions, in which two devices may interact to facilitate payment.

[0024] "Interaction data" can include data related to the interaction and / or data recorded during the interaction. In some implementations, interaction data can be transaction data of network data. Transaction data can include multiple data elements with data values.

[0025] A “credential” can include any evidence of authorization, rights, or privileges. For example, an access credential can include permission to access certain tangible or intangible assets (such as buildings or documents). Examples of credentials can include passwords, passcodes, or confidential messages. In another example, a payment credential can include any suitable information associated with and / or identifying an account (e.g., a payment account and / or a payment device associated with that account). This information can be directly related to the account or can be derived from information associated with the account. Examples of account information can include “account identifiers” such as PAN (primary account number or “account number”), tokens, sub-tokens, gift card numbers or codes, prepaid card numbers or codes, usernames, expiration dates, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, and so on. An example of a PAN is a 16-digit number, such as “4147 0900 0000 1234”. In some implementations, credentials can be considered sensitive information. A “flexible credential” can be a credential associated with multiple sources, such as multiple payment account sources. "Flexible credentials" can take the form of a PAN or a token. "True credentials" can be an account that identifies a specific account. For example, a true credential can be a primary account associated with an account maintained by an authorized entity's computer.

[0026] A “token” may include a substitute identifier for some information. For example, an interaction token may include an identifier for an interaction account, which is a substitute for an account identifier such as a primary account (PAN). For example, a token may include a series of alphanumeric characters that can be used as a replacement for the original account identifier. For example, the token “4900 0000 0000 0001” can be used in place of the PAN “4147 0900 0000 1234”. In some embodiments, the token may be “preserved format” and may have a numeric format consistent with account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, the token may be a random string. In some embodiments, the token may be used in place of the PAN to initiate, authorize, settle, or resolve transactions. In other systems where original credentials are typically provided, the token may also be used to represent the original credentials. In some embodiments, a token value may be generated such that the original PAN or other account identifier may not be recoverable from the token value through computation. Furthermore, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.

[0027] "Tokenization" can include the process of replacing data with replacement data. For example, an account identifier (e.g., a master account (PAN)) can be tokenized by replacing the account identifier with a replacement number (e.g., a token) associated with the account identifier. Furthermore, tokenization can be applied to other information that can be replaced by replacement values. Tokenization can be used to improve transaction efficiency, enhance transaction security, increase service transparency, or provide third-party implementation methods.

[0028] A "token service provider" may include an entity containing one or more server computers that generate, process, and / or maintain tokens. The token service provider may include or communicate with a token store, in which generated tokens are stored. Specifically, the token store may maintain a one-to-one mapping between tokens and data represented by the tokens (e.g., real account identifiers). The token service provider may provide reports or data outputs to reporting tools regarding approved, pending, and / or rejected token requests. The token service provider may provide data outputs related to token-based transactions to reporting tools and applications, and appropriately present the tokens and / or data replaced by the tokens (e.g., real account identifiers) in the report outputs.

[0029] A token vault may include a repository that maintains the established token-PAN mappings. Depending on the implementation, the token vault may also maintain other attributes of the token requester, which can be determined at registration and used by the token server to apply domain restrictions or other controls during transaction processing.

[0030] An "authorization request message" can be an electronic message requesting authorization for an interaction. In some implementations, the authorization request message is sent to the transaction processing computer and / or the issuer of the payment card to request transaction authorization. Authorization request messages according to some implementations may conform to International Organization for Standardization (ISO) 8583, a standard for systems exchanging information about electronic transactions associated with payments made by a user using a payment device or payment account. The authorization request message may include an issuer account identifier that can be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information," including (by example only): service code, CVV (card verification value), dCVV (dynamic card verification value), PAN (primary account number or "account number"), payment token, username, expiration date, etc. The authorization request message may also include "transaction information," such as any information associated with the current transaction, such as transaction value, merchant identifier, merchant location, acquiring bank identification number (BIN), card acceptor ID, information identifying the item being purchased, and any other information that may be used to determine whether to identify and / or authorize the transaction.

[0031] An "authorization response message" can be a message responding to an authorization request. In some cases, an authorization response message can be an electronic message response to an authorization request message generated by the issuing financial institution or transaction processing computer. By way of example only, an authorization response message may include one or more of the following status indicators: Approved – the transaction is approved; Rejected – the transaction is not approved; or Call Center – further information is pending, and the merchant must call the toll-free authorization number. An authorization response message may also include an authorization code, which can be a code indicating approval of the transaction returned by the credit card issuing bank to the merchant's access device (e.g., a POS device) in response to the authorization request message in an electronic message (directly or via the transaction processing computer). This code can serve as evidence of authorization.

[0032] "Authorizing entity" can be an entity that authorizes a request. Examples of authorizing entities include issuers, government agencies, document repositories, access administrators, etc. Authorizing entities can operate authorized entity computers. "Issuer" can refer to a commercial entity (e.g., a bank) that issues and optionally maintains user accounts. Issuers can also issue payment credentials to consumers that are stored on user devices (such as cellular phones, smart cards, tablets, or laptops, or in some implementations, portable devices).

[0033] A "rule" can include procedures or a set of explicit commands. A rule can instruct how an interaction will be processed. A rule can depend on another rule. A rule can be a user-defined rule set by the user. A rule can also be a resource provider rule set by the resource provider. For example, a user rule could instruct that if the transaction amount is above a threshold, a first source of funding, such as a first funding source, will be used, and if the transaction amount is below the threshold, a second source of funding, such as a second funding source, will be used. A resource provider rule could, for example, state that if the transaction is a debit transaction, a first network processing computer will be used, and if the transaction is a credit transaction, a second network processing computer may be used.

[0034] "Source" can refer to where something is obtained. "Source of funds" can include where funds are obtained. Sources of funds can include accounts, such as user accounts. Accounts can be maintained by the issuer and the authorizing entity. Sources of funds can be specific types of funds. For example, sources of funds can be credit funds, debit funds, points funds, installment payment plan funds, cryptocurrency funds, rewards funds, etc.

[0035] The "Account Issuer Identifier" can include a value representing the issuer of the account. The Account Issuer Identifier can include four to eight digits that can be used to identify the issuer. The Account Issuer Identifier can be a Bank Identifier Number (BIN). The Account Issuer Identifier can be included in credentials such as an account number. For example, the Account Issuer Identifier can be the first N digits of an account number used for an account issued by the issuer. The Account Issuer Identifier can correspond to a specific type of Account Issuer Identifier. Each type of Account Issuer Identifier can indicate how the associated account can be utilized in interactions. For example, the Account Issuer Identifier can be a flexible Account Issuer Identifier that can be used in flexible interactions involving user rules and resource provider rules. The Account Issuer Identifier can be a credit account issuer identifier, a debit account issuer identifier, a cryptocurrency account issuer identifier, etc. An identifier table can be used to identify the type of Account Issuer Identifier.

[0036] An "identifier table" may include a set of data stored in memory as a series of records associated with the type of account issuer identifier. The identifier table may include a list of account issuer identifier ranges, where each range corresponds to a type of account issuer identifier.

[0037] A “processor” can include a device for processing things. In some embodiments, a processor can include any suitable one or more data computing devices. A processor can include one or more microprocessors that work together to achieve a desired function. A processor can include a CPU that includes at least one high-speed data processor sufficient to execute program components for performing user and / or system-generated requests. A CPU can be a microprocessor, such as AMD’s Athlon, Duron, and / or Opteron; IBM and / or Motorola’s PowerPC; IBM and Sony’s Cell processors; Intel’s Celeron, Itanium, Pentium, Xeon, and / or XScale; and / or similar processors.

[0038] "Memory" can be any suitable one or more devices capable of storing electronic data. Suitable memory can include non-transient computer-readable media whose storage can be executed by a processor to implement desired methods. Examples of memory can include one or more memory chips, disk drives, etc. Such memory can be operated using any suitable electrical, optical, and / or magnetic modes of operation.

[0039] A "server computer" can include a powerful computer or cluster of computers. For example, a server computer can be a mainframe, a small cluster of computers, or a group of servers operating as a single unit. In one example, a server computer can be a database server coupled to a web server. A server computer can include one or more computing devices and can use any of a variety of computing architectures, arrangements, and compilations to serve requests from one or more client computers.

[0040] The implementation plan allows for a new type of flexible credential that includes an account issuer identifier (e.g., a Bank Identifier Number (BIN)), enabling flexible funding sources based on the characteristics of the current interaction. During an interaction between a resource provider and a user, the user can choose to use a credential associated with a flexible account issuer identifier, which can be associated with multiple funding sources. When the credential is obtained, the resource provider may not know which funding source will be used for the interaction, but can guarantee payment during the interaction. This represents a technological shift in how the industry operates today, where, because the BIN is associated with a specific card product, it is equivalent to a specific processing and specific routing option. According to the implementation plan, the new flexible account issuer identifier can be used as a user credential with an initially undetermined funding source, thus giving the user the ability to make decisions about the funding source before or at the time of purchase.

[0041] Currently, BINs are assigned by a network processing computer to authorized entities (such as issuers). A BIN identifies a specific type of card product and funding source, such as a debit card, credit card, prepaid card, or charge card. This information is recorded in a database within the network processing computer and is available throughout the processing system (e.g., via an API) through multiple channels. The funding source of a BIN is currently immutable and static after allocation, meaning that a user switching an account from debit to credit must always be issued a new card number from a different BIN.

[0042] The implementation solution addresses these technical challenges by creating and utilizing a flexible account issuer identifier within the flexible credentials. When an interaction is processed, the system can determine the source of funds associated with the flexible credentials at any point in time via 1) a rules engine and / or 2) requesting information from the computer within the system.

[0043] To address the technical challenges of limited BIN usage and to create multiple routing options and funding sources, the network processing computer and / or the transmission computer can route interactions to the appropriate network processing computer based on both the resource provider's preferences and the user's choices (e.g., indicated by resource provider rules and user rules, respectively). For example, a resource provider might prefer or be required to use a non-affiliated domestic debit network for routing purposes; this can be set as a rule. If the authorization request message contains flexible credentials, the resource provider computer can indicate the routing preference in the authorization request message. The routing preference can depend on the user's preferred credentials associated with the flexible credentials. For example, if a debit funding source is selected as the user's funding choice according to user rules, the network processing computer can route an interaction including details of the debit funding source to the appropriate non-affiliated network for processing. Similarly, if a completely different funding source, such as cryptocurrency, is requested, the issuer / wallet can communicate directly with the cryptocurrency computer to facilitate the interaction.

[0044] The implementation reduces the computational resource burden on network processing computers and the ecosystem because interactions can be routed based on funding sources chosen by users (e.g., user rules) and resource provider choices (e.g., resource provider rules), eliminating the need to confirm multi-party rules via multiple messages before interaction. This reduction in the total number of messages utilized provides technical improvements in latency across the entire network processing computer and reduces the overall computational requirements of the system.

[0045] In some implementations, rules can be created and set by users, resource providers, acquirers, network processors, issuers, etc. In other implementations, artificial intelligence models can be used to generate rules. For example, AI models such as recommendation engines can provide users with funding source recommendations via smart rules, which can optimize selection and reduce checkout time, thereby allowing for higher throughput and less hardware in the checkout lane. Machine learning models can be used to recommend rules based on regular interactions. Machine learning models can also be used to create rule recommendations that suggest appropriate funding sources based on past behavior. Alternatively, users can choose to utilize user rules with custom settings or user rules created by machine learning models (e.g., always use debit to pay for supermarket shopping, always use airline A's co-branded card to pay for airline A's shopping, always use a multi-currency account to settle cross-border shopping, etc.). Machine learning models can also implement "decide for me" models, where the user authorizes the system to determine the appropriate account for application transactions.

[0046] Figure 1A system 100 according to an embodiment of the present disclosure is shown. The system 100 includes a user device 102, an access device 104, a resource provider computer 106, a transmission computer 108, multiple network processing computers 110, an authorization entity computer 112, a user rules database 114, an identifier table database 116, and a resource provider rules database 118.

[0047] User equipment 102 can perform operational communication with access device 104. Access device 104 can perform operational communication with resource provider computer 106, which can perform operational communication with transmission computer 108. Transmission computer 108 can perform operational communication with multiple network processing computers 110. Multiple network processing computers can perform operational communication with authorizing entity computer 112. Each of the multiple network processing computers can perform operational communication with each other.

[0048] User rule database 114 can communicate operationally with authorized entity computer 112, multiple network processing computers 110, and transmission computer 108. Identifier table database 116 can communicate operationally with authorized entity computer 112, multiple network processing computers 110, transmission computer 108, and resource provider computer 106. Resource provider rule database 118 can communicate operationally with multiple network processing computers 110, transmission computer 108, and resource provider computer 106.

[0049] To simplify the explanation, Figure 1 A specific number of components are shown. However, it should be understood that embodiments of the invention may include more than one of each component. Furthermore, some embodiments of the invention may include more than one of each component. Figure 1 All components shown may be few or many. For example, in some implementations, there may be multiple authorized entity computers.

[0050] Figure 1Messages between devices in the system 100 shown can be transmitted using secure communication protocols such as, but not limited to, File Transfer Protocol (FTP); Hypertext Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS); SSL; ISO (e.g., ISO 8583); etc. The communication network can include any and / or a combination of the following: direct interconnection; the Internet; a local area network (LAN); a metropolitan area network (MAN); an Operational Mission as a Node on the Internet (OMNI); a secure custom connection; a wide area network (WAN); a wireless network (e.g., employing protocols such as, but not limited to, Wireless Application Protocol (WAP), I-mode, etc.); etc. The communication network can use any suitable communication protocol to generate one or more secure communication channels. In some cases, the communication channels may include secure communication channels that can be established in any known manner, such as by using mutual authentication and session keys, and establishing a Secure Sockets Layer (SSL) session.

[0051] User equipment 102 may include one or more computers, laptops, tablets, mobile devices, cellular phones, wearable devices (e.g., watches, glasses, lenses, clothing, etc.), personal digital assistants (PDAs), Internet of Things (IoT) devices, etc. User equipment 102 can be operated by a user. User equipment 102 can initiate interactions (e.g., transactions) with resource provider computers and / or access devices.

[0052] Access device 104 may include a device operated by a resource provider. For example, access device 104 may include a mobile device, a point-of-sale (POS) terminal, a laptop computer, a desktop computer, etc. Access device 104 may communicate with another device (e.g., user equipment 102) to perform an interaction. During the interaction, access device 104 may receive credentials from the user equipment and may provide interaction data to resource provider computer 106 for authorization of the interaction. In some embodiments, access device 104 may generate an authorization request message that includes at least the interaction data. Access device 104 may provide the authorization request message to resource provider computer 106.

[0053] Resource provider computer 106 may include any suitable computing device operated by a resource provider (e.g., a merchant). In some embodiments, resource provider computer 106 may include one or more server computers that may host one or more websites associated with the resource provider (e.g., a merchant). In some embodiments, resource provider computer 106 may be configured to send data to network processing computer 110 via transport computer 108 as part of a payment verification and / or authentication process for a transaction between a user (e.g., a customer) and the resource provider. Resource provider computer 106 may also be configured to generate authorization request messages for interaction between the resource provider and the user, and route the authorization request messages to authorization entity computer 112 for interaction processing.

[0054] The transmission computer 108 may include a server computer. The transmission computer 108 may be associated with an acquirer, which may be an entity with a business relationship with a particular merchant or other entity (e.g., a commercial bank). Some entities may perform both issuer and acquirer functions. Some implementations may encompass such a single entity as an issuer-acquirer.

[0055] Multiple network processing computers 110 may include network processing computers that can function as server computers. The network processing computers in the multiple network processing computers 110 may be positioned between the transmission computer 108 and the authorization entity computer 112, and between multiple other transmission computers and the authorization entity computer (not shown). The network processing computer may include a data processing subsystem, a network, and operations for supporting and transmitting authorization services, exception document services, and clearing and settlement services. For example, the network processing computer may include a server coupled to a network interface (e.g., via an external communication interface), and an information database. The network processing computer may represent a transaction processing network. An exemplary transaction processing network may include VisaNet™. Transaction processing networks such as VisaNet™ are capable of processing credit card transactions, debit card transactions, and other types of commercial transactions. Specifically, VisaNet™ includes a VIP system (Visa Integrated Payment System) that processes authorization requests, and a Base II system that performs clearing and settlement services. The network processing computer may use any suitable wired or wireless network, including the Internet.

[0056] Authorized entity computer 112 may include a server computer operated by the authorized entity. Authorized entity computer 112 may be associated with an authorized entity, which may be the entity that issued the authorization request. Examples of authorized entities may be issuers, which typically refer to commercial entities (e.g., banks) that maintain user accounts. Issuers may also issue and manage accounts associated with user device 102.

[0057] User rule database 114 may include a database storing user rules. User rule database 114 may store user rules in association with user credentials or other user identification data such as tokens, user identifiers, etc. User rule database 114 may be a database maintained by a transmission computer 108, a network processing computer among multiple network processing computers 110, or an authorized entity computer 112.

[0058] User rule database 114 can store user rules created by users. For example, users can access the user rule creation platform via authorized entity computer 112 or other computers to create, modify, and remove user rules.

[0059] User rules can specify how interactions with flexible credentials will be handled. User rules can also specify how to select a particular funding source from multiple sources based on characteristics of the current interaction. For example, user rules can modify the funding source used for an interaction based on the interaction amount, previous interaction, date, time, location, currency, current reward amount, current points amount, and / or any other characteristics of the interaction and / or the device and entity involved in the interaction.

[0060] The identifier table database 116 may include one or more identifier tables. Identifier tables can be used to identify the type of account issuer identifier using a range of account issuer identifiers. Identifier tables can store ranges of account issuer identifiers and map these ranges to specific types (e.g., flexible) of account issuer identifiers. For example, the range of account issuer identifiers from 0000 to 2999 can be mapped to the flexible account issuer identifier type. And the range of account issuer identifiers from 3000 to 5999 can be mapped to the debit account issuer identifier type.

[0061] Resource provider rule database 118 may include a database storing resource provider rules. Resource provider rule database 118 may store resource provider rules associated with resource provider identifiers. Resource provider rule database 118 may be maintained by transport computer 108 and may store resource provider rules for resource providers associated with transport computer 108. Different transport computers may maintain different resource provider rules.

[0062] Resource provider rules may govern how interactions will be processed based on funding sources determined by user rules. Resource provider rules may be dependent on user rules. Resource provider rules may govern selecting a specific method for processing an interaction based on funding sources. In some cases, resource provider rules may relate to any data included in the interaction. For example, resource provider rules may modify the method of processing an interaction based on funding sources and may define which of a plurality of network processing computers will process the interaction. Resource provider rules may also include rules governing how the resource provider may wish to modify or add content to an authorization request message or authorization response message, or how the resource provider may wish to apply certain security rules (e.g., fraud rules) to authorization request messages.

[0063] Figure 1 Devices within the network can use API commands to access the user rules database 114, the identifier table database 116, and the resource provider rules database 118. The user rules database 114, the identifier table database 116, and the resource provider rules database 118 can be maintained by a network processing computer among multiple network processing computers 110. In some implementations, the user rules database 114 can be maintained by the authorizing entity computer 112 that issues accounts to users, while the resource provider rules database 118 is maintained by the delivery computer 108 for resource providers associated with the delivery computer 108.

[0064] In some implementations, one or more databases may exist within each database. For example, multiple user rule databases may exist, with each user rule database maintained by a different network processing computer among multiple network processing computers.

[0065] The user rules database 114, the identifier table database 116, and the resource provider rules database 118 may include any suitable database. The database may be a general-purpose, fault-tolerant, relational, scalable, and secure database, such as one available from Oracle™ or Sybase™.

[0066] Figure 2 A block diagram of a transmission computer 108 according to an embodiment is shown. The exemplary transmission computer 108 may include a processor 204. The processor 204 may be coupled to a memory 202, a network interface 206, and a computer-readable medium 208. The computer-readable medium 208 may include modules. The computer-readable medium 208 may include a rule determination module 208A and a rule application module 208B.

[0067] Memory 202 can be used to store data and code. For example, memory 202 can store interaction data, routing tables, user rules, resource provider rules, etc. Memory 202 can be coupled internally or externally to processor 204 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (such as RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0068] Computer-readable medium 208 may include code executable by processor 204 to perform a method comprising: receiving an authorization request message from a resource provider computer operated by a resource provider, the authorization request message including credentials and amounts for a transaction between a user and a resource provider, the credentials being associated with multiple sources of funds; determining a subset of user rules from a set of user rules associated with the credentials to be applied to the transaction; determining a subset of resource provider rules of the resource provider based on the subset of user rules to be applied to the transaction; and applying the subset of user rules and the subset of resource provider rules to the transaction.

[0069] The rule determination module 208A may include code or software executable by the processor 204 for determining rules. The rule determination module 208A, in conjunction with the processor 204, can determine user rules and resource provider rules. The rule determination module 208A, in conjunction with the processor 204, can determine a subset of user rules from the set of user rules associated with the credentials in the authorization request message to be applied to the interaction. The rule determination module 208A, in conjunction with the processor 204, can determine a subset of resource provider rules based on the subset of user rules to be applied to the transaction.

[0070] To determine user rules, in some implementations, credentials may include an account issuer identifier, which may fall within a range of account issuer identifiers in the identifier table database 116. If the account issuer identifier is within a range indicating that the account issuer identifier is a flexible account issuer identifier, then the rule determination module 208A, in conjunction with processor 204, can determine that the current interaction utilizes user rules from the user rule database 114. The rule determination module 208A, in conjunction with processor 204, can search the user rule database 114 for a set of user rules associated with the credentials. The rule determination module 208A, in conjunction with processor 204, can evaluate the set of user rules to determine a subset of user rules relevant to the current interaction. For example, the current interaction may include an amount of $600, and the rule determination module 208A, in conjunction with processor 204, can identify a subset of user rules satisfied by an amount of $600. For example, a first user rule may instruct the use of a first account maintained by an authorized entity computer to process interactions with amounts greater than $500. The rule determination module 208A, in conjunction with processor 204, can identify a first user rule used in the current interaction.

[0071] In other embodiments, the rule determination module 208A, in conjunction with processor 204, can identify one or more selected user rules in the authorization request message for use as a subset of user rules. For example, when initiating an interaction, a user can select one or more user rules on user device 102 and / or access device 104. One or more selected user rules can be added to the authorization request message or provided together with an authorization request message from resource provider computer 106. The rule determination module 208A, in conjunction with processor 204, can utilize credentials in the authorization request message to search for user preferences regarding rule priority in user rule database 114. The rule determination module 208A, in conjunction with processor 204, can determine that selected user rules during the interaction take precedence over pre-selected and stored user rules. The rule determination module 208A, in conjunction with processor 204, can determine to utilize one or more selected user rules.

[0072] To determine resource provider rules, in some implementations, rule determination module 208A, in conjunction with processor 204, can identify resource provider rules in resource provider rule database 118. The authorization request message may include interaction data, which includes a resource provider identifier. Rule determination module 208A, in conjunction with processor 204, can use the resource provider identifier to identify a set of resource provider rules for a resource provider in resource provider rule database 118. Rule determination module 208A, in conjunction with processor 204, can identify a subset of resource provider rules in the set of resource provider rules based on a subset of user rules. Resource provider rules may depend on user rules. For example, user rules may indicate a funding source among multiple funding sources, while resource provider rules indicate the network processing computer to be utilized based on the indicated funding source.

[0073] In other implementations, the rule determination module 208A, in conjunction with the processor 204, may identify a subset of resource provider rules received in or along with an authorization request message received from the resource provider computer 106.

[0074] The rule application module 208B may include code or software executable by the processor 204 for applying rules. The rule application module 208B, in conjunction with the processor 204, can apply user rules and resource provider rules to the interaction. The rule application module 208B, in conjunction with the processor 204, can apply user rules and resource provider rules to appropriately route authorization request messages to the network processing computer and the authorization entity computer for authorization.

[0075] In some implementations, the rule application module 208B, in conjunction with the processor 204, can modify the authorization request message based on user rules and / or resource provider rules. For example, the rule application module 208B, in conjunction with the processor 204, can modify the authorization entity identifier in the authorization request message based on user rules that indicate a specific account used for the interaction. As another example, the rule application module 208B, in conjunction with the processor 204, can modify the network processing computer identifier in the authorization request message based on resource provider rules that indicate a specific network processing computer used to process the interaction.

[0076] Network interface 206 may include an interface that allows the transmitting computer 108 to communicate with external computers. Network interface 206 enables the transmitting computer 108 to transmit data to and from another device (such as resource provider computer 106, network processing computers among multiple network processing computers 110, etc.). Some examples of network interface 206 may include a modem, a physical network interface (such as an Ethernet card or other network interface card (NIC)), a virtual network interface, a communication port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, etc. Wireless protocols enabled by network interface 206 may include Wi-Fi. TM Data transferred through network interface 206 may be in the form of signals, which may be electrical signals, electromagnetic signals, optical signals, or any other signals that can be received by an external communication interface (collectively, "electronic signals" or "electronic messages"). These electronic messages, which may contain data or instructions, may be provided between network interface 206 and other devices via a communication path or channel. As described above, any suitable communication path or channel may be used, such as wires or cables, optical fibers, telephone lines, cellular links, radio frequency (RF) links, WAN or LAN networks, the Internet, or any other suitable medium.

[0077] Figure 3 A block diagram of a network processing computer 300 according to an embodiment is shown. The exemplary network processing computer 300 may include a processor 304. The processor 304 may be coupled to a memory 302, a network interface 306, and a computer-readable medium 308. The computer-readable medium 308 may include modules. The computer-readable medium 308 may include a rule determination module 308A, a rule application module 308B, a tokenization module 308C, and a routing module 308D. The network processing computer 300 can operatively communicate with a database 310.

[0078] Memory 302 can be used to store data and code. For example, memory 302 can store interaction data, routing tables, user rules, resource provider rules, etc. Memory 302 can be coupled internally or externally to processor 304 (e.g., a cloud-based data storage device) and can include any combination of volatile and / or non-volatile memory (e.g., RAM, DRAM, ROM, flash memory, or any other suitable memory device).

[0079] Computer-readable medium 308 may include code executable by processor 304 to perform a method comprising: receiving an authorization request message from a resource provider computer operated by a resource provider, the authorization request message including credentials and amounts for a transaction between a user and a resource provider, the credentials being associated with multiple sources of funds; determining a subset of user rules from a set of user rules associated with the credentials to be applied to the transaction; determining a subset of resource provider rules of the resource provider based on the subset of user rules to be applied to the transaction; and applying the subset of user rules and the subset of resource provider rules to the transaction.

[0080] The rule determination module 308A can be similar to the rule determination module 208A, and the rule application module 308B can be similar to the rule application module 208B, and will not be repeated.

[0081] The tokenization module 308C can work with the processor 304 to perform tokenization, detoxification, and ciphertext verification.

[0082] Database 310 can store the mapping from real credentials to flexible credentials, as well as real credentials, flexible credentials, and associated rules and routing information. Database 310 can store multiple real credentials and multiple flexible credentials. Each real credential and each flexible credential can be stored in association with user identification data, which may include a user identifier, user device identifier, username, or other information uniquely identifying the user. Each of the multiple flexible credentials can be associated with one or more real credentials based on user rules. Database 310 can be a credential mapping database and can be a conventional, fault-tolerant, relational, scalable, and secure database, such as those commercially available from Oracle™ or Sybase™.

[0083] The routing module 308D may include code or software executable by the processor 304 to route authorization request messages and authorization response messages to and from the alternative network processing computer, the authorizing entity computer, and the transmission computer. The routing module 308D, in conjunction with the processor 304, may determine the destination computer based on the current message and user rules and / or resource provider rules. For example, resource provider rules for the current interaction may instruct the interaction to be handled by the alternative network processing computer that handles cryptocurrency-based interactions. The routing module 308D, in conjunction with the processor 304, may format the authorization request message so that it can be read by the alternative network processing computer. Instead of forwarding the authorization request message to the authorizing entity computer, the routing module 308D, in conjunction with the processor 304, may provide the authorization request message to the alternative network processing computer based on resource provider rules.

[0084] Network interface 306 may include (similar to or different from) a means that allows network processing computer 300 to communicate with external computers. Figure 2 The network interface 206 in the middle.

[0085] Figure 4 A flowchart illustrating an interaction processing method according to an implementation scheme is shown. It will be described in the context of user operation of user device 102 and the interaction performed by the resource provider with the resource provider computer 106. Figure 4 The method described herein. This interaction can be a transaction in which a user obtains a specific resource from a resource provider. However, it should be understood that the system can handle other types of interactions. For example, the interaction may include a request to access a secure webpage, a request to access and transfer data, a request to access a secure location, etc.

[0086] Unlike existing BIN ranges, the new Flexible Account Issuer Identifier (BIN) range will not have predefined product-level characteristics. Flexible credentials with a Flexible Account Issuer Identifier are not directly assigned to user accounts on a one-to-one basis. The computer examining the Flexible Account Issuer Identifier will not be able to make any assumptions about how to fund interactions, thus providing the advantage of user privacy. The computer storing or maintaining a database of user rules in the system can determine how to fund interactions. Users can determine the source of funds at the point of sale or via a predefined configuration of user rules that allocates the source of funds based on the characteristics of the interaction. For example, users can use the following rules to set up their credentials: 1) If the interaction involves an amount less than $50, payment is made using a credit account; 2) If the interaction involves an amount between $50 and $500, payment is made using an installment plan; and 3) If the interaction involves an amount greater than $500, payment is made using a credit account.

[0087] In some implementations, prior to the interaction, the resource provider computer 106 may obtain one or more identification tables from one or more network processing computers, including network processing computer 300. The identification tables may indicate ranges of account issuer identification numbers for use with account issuer identification numbers. Each range of account issuer identification numbers may correspond to a different type of account issuer identification number. For example, a first range of account issuer identification numbers may correspond to flexible account issuer identification numbers, a second range may correspond to installment plan account issuer identification numbers, and a third range may correspond to credit account issuer identification numbers. During the interaction, credentials may indicate a specific type of account issuer identification number used for the interaction.

[0088] For example, at step 402, the identification table database 116 may provide the identification table to the transmission computer 108 in response to a request for the identification table. In some embodiments, the identification table may be pushed from the identification table database 116 to the transmission computer 108 by the network processing computer 300.

[0089] At step 404, the transmitting computer 108 may provide an identification table to the resource provider computer 106 for use in the interaction to determine the type of account issuer identification number for each interaction.

[0090] At step 406, user equipment 102 may initiate an interaction with resource provider computer 106. For example, user equipment 102 may initiate the interaction via a webpage hosted by resource provider computer 106. In some embodiments, user equipment 102 may communicate with an access device (not shown). User equipment 102 may provide flexible credentials to resource provider computer 106. User equipment 102 may indicate which specific resources to obtain from the resource provider for the interaction.

[0091] The authorizing entity of the authorizing entity computer 112 can issue flexible credentials to users of user equipment 102. The flexible credentials may include an account issuer identifier for the authorizing entity. In some implementations, the account issuer identifier may be a flexible account issuer identifier (e.g., a flexible BIN). The flexible account issuer identifier may indicate that the flexible credentials are associated with one or more sources of funds (e.g., associated with a first debit account, a second debit account, a first credit account, a second credit account, a loyalty points account, etc.). The flexible account issuer identifier may be part of an account number (such as the primary account number (PAN) included in the flexible credentials). For example, the flexible account issuer identifier may include the first 4, 5, 6, 7, 8, 10, 14, etc., digits of the account number.

[0092] In some implementations, flexible credentials may include tokens instead of a primary account to enhance security. Tokens can be assigned to token-based account issuer identifier ranges, which function similarly to account-based account issuer identifier ranges. Token account issuer identifier ranges can have the same characteristics as the underlying account, allowing resource provider computers to route interactions in a manner similar to non-tokenized interactions.

[0093] In some implementations, when interacting with a resource provider's computer via a digital wallet application installed on user device 102, the user may be prompted to select a source of funds within the digital wallet application during the interaction. Alternatively, the user may be prompted to select a source of funds on the access device. Different approaches may exist where the user of user device 102 can instruct how funds will be provided for the interaction or other processing will be performed based on selected user rules.

[0094] At step 408, after receiving the flexible credentials from user equipment 102 for interaction, resource provider computer 106 can compare the account issuer identifier from the flexible credentials with an identifier table. Resource provider computer 106 can store one or more identifier tables, each of which can be created by and received from different network processing computers from different networks via transmission computer 108. Resource provider computer 106 can determine that the account issuer identifier is a flexible account issuer identifier and corresponds to multiple sources (e.g., multiple funding sources).

[0095] At step 410, the resource provider computer 106 may generate an authorization request message that includes flexible credentials and amounts for interactions between the user and the resource provider. The resource provider computer 106 may provide the authorization request message to the transmitting computer 108.

[0096] The authorization request message may also include interactive data. Interactive data may include resource provider identifier, amount, time, date, transmitting computer identifier, resource identifier, etc.

[0097] In some implementations, the authorization request message may also include resource provider rules. Resource provider rules can instruct rules on how the interaction should be processed. For example, resource provider computer 106 may include resource provider rules to instruct delivery computer 108 that if the interaction is a debit transaction (e.g., a flexible account issuer identifier is determined to be used with a source of funds corresponding to a debit account), the interaction should be routed to an alternative network processing computer. Resource provider rules can also instruct that if the interaction is a credit transaction (e.g., a flexible account issuer identifier is determined to be used with a source of funds corresponding to a credit account), the interaction should be routed to a specific network processing computer (e.g., network processing computer 300). Resource provider rules may be in the form of codes representing rules stored at network processing computer 300.

[0098] Resource provider rules can be created by the resource provider and can instruct how interactions will be processed. Resource provider rules can be dependent on user rules. For example, resource provider rules can instruct that if the interaction is in a first currency, the interaction will be processed through a first network processing computer located in a first geographical location; and if the interaction is in a second currency, the interaction will be processed through a second network processing computer located in a second geographical location.

[0099] In some implementations, the resource provider computer 106 may provide resource provider rules to the transmission computer 108 prior to the interaction, wherein the transmission computer 108 stores the resource provider rules to be used during the interaction in the resource provider rules database 118.

[0100] For example, at step 412, after receiving the authorization request message, the transport computer 108 can use the resource provider identifier included in the authorization request message to identify resource provider rules in the resource provider rule database 118. The transport computer 108 can obtain a superset of resource provider rules associated with the resource provider computer 106. The transport computer 108 can identify resource provider rules related to the current interaction and can create a set of resource provider rules from these resource provider rules.

[0101] At step 414, after receiving the authorization request message, the transmitting computer 108 may provide the network processing computer 300 with an authorization request message that includes a set of amounts, flexible credentials, and resource provider rules.

[0102] At step 416, the network processing computer 300 can determine a subset of the user rules to be applied to the interaction from the set of user rules associated with the flexible credentials. The network processing computer 300 can store and maintain the user rules in the user rule database 114.

[0103] For example, network processing computer 300 can identify a set of user rules associated with flexible credentials. For example, network processing computer 300 can request a set of user rules stored in association with credentials from user rule database 114. User rule database 114 can provide network processing computer 300 with a set of user rules related to credentials.

[0104] After obtaining the set of user rules, the network processing computer 300 can determine a subset of user rules based on the set of user rules. The subset of user rules may include user rules applicable to the current interaction. For example, user rules may be applied to the interaction based on information about the interaction, such as date, time, amount of the interaction, location of the interaction, currency of the interaction, etc.

[0105] For example, a first rule could be: each interaction on a first document associated with a flexible account issuer ID should be processed on a second document associated with a specific account issuer ID associated with a debit account. A second rule could be: if the interaction involves an amount greater than $200 on the first document associated with a flexible account issuer ID, the interaction should be processed on the second document associated with a specific account issuer ID associated with a debit account; otherwise, the interaction should be processed on a third document associated with a specific account issuer ID associated with a credit account. A third rule could be: if the interaction is in British pounds (GBP) on the first document associated with a flexible account issuer ID, the interaction should be processed on the second document associated with a specific account issuer ID associated with a debit account in GBP; otherwise, the interaction should be processed on the third document associated with a specific account issuer ID associated with a credit account in US dollars (USD). The fourth rule could be: for the next interaction of a first document associated with the issuer identifier of the flexible account, the interaction should be processed on a second document associated with the specific account issuer identifier associated with the debit account, and then restored to a third document associated with the specific account issuer identifier associated with the credit account.

[0106] Network processing computer 300 can select a real credential associated with an identified source (e.g., source of funds) and can replace the flexible credential with the real credential in the authorization request message before forwarding the authorization request message to the authorization entity computer 112 associated with the flexible credential and the real credential. Network processing computer 300 can store the mapping from flexible credentials to the real credentials associated with those flexible credentials in a database (e.g., ...). Figure 3 In 310), for example, network processing computer 300 can modify the authorization request message by removing the flexible credential from the authorization request message and adding the real credential to the authorization request message.

[0107] In some implementations, user rules related to interaction processing for different users can be stored and / or determined by a rule engine that includes machine learning models. The rule engine can be maintained by the network processing computer 300. The rule engine can store dynamic rules regarding the source of funds.

[0108] As an example, a rule engine could be a recommendation engine that recommends user rules to users. A recommendation engine could also be an artificial intelligence system that recommends things to users. Recommendation engines can use machine learning models to determine interaction patterns, user behavior, user preferences, and so on to recommend user rules to users.

[0109] The recommendation engine can be trained using data such as ratings, reviews, interaction success rates, user behavior, and / or any other data related to the interaction and / or the devices and entities involved. User behavior can include, for example, reviews, preferences, browsing history, digital shopping cart events, past interactions, search history, etc.

[0110] The recommendation engine can be a collaborative filtering system, a content-based filtering system, or a hybrid recommendation system that combines collaborative filtering and content-based filtering.

[0111] Collaborative filtering systems can filter recommendations based on the similarity between a specific user and other users. Collaborative recommendation systems can rely on both explicit and implicit data and assume that users with similar preferences are likely to be interested in the same items and may interact with these items in a similar manner in the future. There are two main types of collaborative filtering systems that can be implemented to determine user rule recommendations: memory-based and model-based. Memory-based systems can represent users and items as matrices and can be an extension of the k-nearest neighbor (KNN) algorithm, as the goal of memory-based systems is to find nearest neighbors, which can be similar users or similar user rules. Model-based systems create and utilize predictive machine learning models from the data. The user-item matrix can be used as a training dataset for the machine learning model, which can generate predictions for missing values ​​(i.e., user rules that the user has not yet utilized and will therefore be recommended).

[0112] Content-based filtering systems can filter recommendations based on features of user rules. Content-based recommendation systems can assume that if a user is associated with a specific user rule, then the user can also be associated with another similar user rule. Content-based filtering considers item descriptions such as category, price, and other metadata assigned by keywords and tags, as well as explicit and implicit data. Content-based filtering systems can represent user rules and users as vectors in a vector space. Proximity is used to determine the similarity between user rules. The closer two vectors are in space, the more similar they are considered. Vectors similar to previous user rules based on the supplied features are recommended to the user. Content-based recommendations can apply user-based classifiers or regression models.

[0113] At step 418, after determining the subset of user rules, the network processing computer 300 may determine a subset of resource provider rules based on the subset of user rules to be applied to the interaction. The network processing computer 300 may determine the subset of resource provider rules based on: 1) the interaction, 2) the subset of user rules, and 3) the set of resource provider rules received from the transmitting computer 108.

[0114] For example, network processing computer 300 can analyze a set of resource provider rules to determine whether one or more resource provider rules apply to both the user rules within a subset of interaction and user rules. Network processing computer 300 can filter the set of resource provider rules using characteristics of the interaction, such as interaction amount, date, time, devices and entities involved, location, currency type, etc. For example, the current interaction might occur in California. The set of resource provider rules could include different resource provider rules for different states in the United States. Network processing computer 300 can filter the set of resource provider rules by location. Network processing computer 300 can further filter the set of resource provider rules using a subset of user rules. For example, user rules might indicate that a specific cryptocurrency will be used to process the interaction. Network processing computer 300 can filter resource provider rules based on the use of cryptocurrency. For example, network processing computer 300 can determine that a resource provider rule that uses an alternative network processing computer to process a cryptocurrency-based interaction can be selected as a resource provider rule applicable to the current interaction and to be included in the subset of resource provider rules.

[0115] As another example, a subset of user rules could include a rule that the interaction will be processed using a debit account maintained by the authorized entity computer 112 when the interaction amount is less than $10. The network processing computer 300 could also determine that if the current interaction has an interaction amount less than $10, the resource provider rule "use network processing computer 300 to process debit account-related interactions" applies to the current interaction.

[0116] At step 420, network processing computer 300 may apply a subset of user rules and a subset of resource provider rules to the interaction. As an example, the subset of user rules may include user rules instructing the use of a first account to process the interaction, which may be a loyalty points account maintained by authorization entity computer 112. The subset of resource provider rules may include resource provider rules instructing the use of network processing computer 300 to process the interaction if it relates to loyalty points. Therefore, network processing computer 300 can process the interaction and prepare to provide an authorization request message to authorization entity computer 112. In some embodiments, applying rules to the interaction may include executing logic included in the rules to modify how the interaction itself is processed.

[0117] At step 422, after applying a subset of the user rules and a subset of the resource provider rules to the interaction, the network processing computer 300 may provide the authorizing entity computer 112 with an authorization request message including the transaction amount and authentic credentials associated with the selected source of funds. Therefore, the network processing computer 300 may provide authentic credentials to the authorizing entity computer 112 for authorization instead of flexible credentials. Authentic credentials may indicate a specific source of funds, such as a specific account maintained by the authorizing entity computer 112. Authentic credentials may be the primary account number identifying the account.

[0118] At step 424, after receiving an authorization request message from network processing computer 300 including the transaction amount and authentic credentials associated with the selected source of funds, authorization entity computer 112 can determine whether to authorize the interaction. Authorization entity computer 112 can determine whether to authorize the interaction based on any criteria related to the user, user device 102, resource provider, resource provider computer 106, account, interaction, determined risk score, etc. Authorization entity computer 112 can generate an indication of whether the interaction is authorized.

[0119] Authorizing entity computer 112 can generate an authorization response message that includes an indication of whether the interaction is authorized. Authorizing entity computer 112 may also include indications of how the interaction is processed and / or authorized. For example, authorizing entity computer 112 may include information related to the type of account used for the interaction (e.g., a loyalty points account). Therefore, the authorization response message can indicate which type of funding source was used for the interaction and may include credential verification. This information may be beneficial to resource provider computer 106, because at this point in the process, resource provider computer 106 may not know what type of source (e.g., funding source) is being used for the interaction (e.g., funding source data).

[0120] At step 426, after generating the authorization response message, the authorization entity computer 112 may provide the authorization response message to the network processing computer 300.

[0121] At step 428, after receiving the authorization response message, the network processing computer 300 may provide the authorization response message to the transmitting computer 108. The network processing computer 300 may replace the real credential with a flexible credential. For example, the network processing computer 300 may identify the flexible credential based on the real credential. The network processing computer 300 may modify the authorization response message to remove the real credential and add the flexible credential. By doing so, when communicating with the transmitting computer 108 and the resource provider computer 106, the system can address the technical problem of real credential security by switching the real credential with a flexible credential.

[0122] At step 430, the transmitting computer 108 may provide an authorization response message to the resource provider computer 106.

[0123] At step 432, after receiving the authorization response message from the transmitting computer 108, the resource provider computer 106 may provide the user equipment 102 with the authorization response message and / or an indication of whether the interaction is authorized.

[0124] Figure 5 A flowchart illustrating an interactive processing method including an alternative network processing computer according to an embodiment is shown. It will be described in the context of user operation of user equipment 102 and interaction with the resource provider computer 106. Figure 5 The method described herein. This interaction could be a transaction in which a user obtains a specific resource from a resource provider. For this interaction, user rules could instruct the use of an installment payment plan, while resource provider rules could instruct the use of an alternative network processing computer 500 to process the installment payment plan.

[0125] Steps 502 to 514 are similar to the reference. Figure 4 Steps 402 to 414 are described and will not be repeated here.

[0126] In some implementations, at step 516, after receiving an authorization request message including flexible credentials and an amount, and after receiving one or more resource provider rules for the interaction, the network processing computer 300 can verify that the flexible credentials are associated with a flexible account issuer identifier. The network processing computer 300 can obtain the account issuer identifier (e.g., the first six digits of the credential) from the credential. The network processing computer 300 can search the identifier table database 116 to determine a range of account issuer identifiers covering the account issuer identifier from the credential. The network processing computer 300 can determine the type of account issuer identifier based on the range of account issuer identifiers. For example, the network processing computer 300 can determine that the account issuer identifier from the credential is a flexible account issuer identifier, and can process the interaction using user rules and resource provider rules.

[0127] At step 518, after identifying the user credentials as associated with the flexible account issuer identifier, the network processing computer 300 can generate a user rule request message including the credentials. The network processing computer 300 can provide the user rule request message to the authorized entity computer 112.

[0128] At step 520, the authorized entity computer 112 can determine a subset of user rules based on the set of user rules stored in the user rules database 114 and associated with credentials.

[0129] At step 522, the authorizing entity computer 112 may generate a user rule response message that includes a subset of the user rules. The authorizing entity computer 112 may provide the user rule response message to the network processing computer 300.

[0130] At step 524, after receiving the user rule response message, the network processing computer 300 can determine which resource provider rules (if any) in the resource provider rules are associated with the subset of user rules to be applied to the interaction. The network processing computer 300 can then apply both the subset of user rules and the subset of resource provider rules to the interaction. In some embodiments, applying rules to the interaction can modify how the interaction processing system processes the interaction. Additionally, applying rules can modify which computers in the interaction processing system should process the interaction.

[0131] For example, a subset of user rules may include rules that utilize the installment plan used for the current interaction. If an installment plan is used to process the current interaction, a subset of resource provider rules may include rules that utilize an alternative network to process the computer.

[0132] Network processing computer 300 can apply user rules and resource provider rules to the interaction by routing the authorization request message to an alternative network processing computer 500. In some implementations, network processing computer 300 may include a subset of user rules and a subset of resource provider rules in the authorization request message.

[0133] The network processing computer 300 can also replace flexible credentials with real credentials in the authorization request message and provide the authorization entity computer 112 with an authorization request message that includes the transaction amount and real credentials associated with the selected source of funds. For example, the network processing computer 300 can identify real credentials indicated in a specific user rule. The network processing computer 300 can remove flexible credentials from the authorization request message and can include real credentials in the authorization request message.

[0134] At step 526, network processing computer 300 may provide an authorization request message, including the authenticity of the credentials and the transaction amount, to alternative network processing computer 500.

[0135] At step 528, after receiving the authorization request message, the alternative network processing computer 500 may perform any additional processing in response to the interaction and / or authorization request message. For example, the alternative network processing computer 500 may use additional communication channels (e.g., email, text messages, etc.) to authenticate the user of user equipment 102. The alternative network processing computer 500 may then provide the authorization request message to the authorization entity computer 112 for authorization.

[0136] At step 530, the authorizing entity computer 112 can determine whether to authorize the interaction and can generate an authorization response message. For example, after receiving an authorization request message, the authorizing entity computer 112 can determine whether to authorize the interaction. The authorizing entity computer 112 can generate an indication of whether the interaction is authorized. The authorizing entity computer 112 can generate an authorization response message that includes an indication of whether the interaction is authorized and the true credentials. In some embodiments, the authorization response message may also include information related to how the interaction is processed (e.g., the interaction is processed as a debit interaction, a credit interaction, an installment payment plan interaction, etc.).

[0137] At step 532, the authorizing entity computer 112 may provide an authorization response message to the alternative network processing computer 500.

[0138] At step 534, after receiving the authorization response message from the authorized entity computer 112, the alternative network processing computer 500 can replace the real credentials with flexible credentials and provide the authorization response message to the network processing computer 300.

[0139] At step 536, the network processing computer 300 may provide an authorization response message to the transmitting computer 108 in response to the authorization request message.

[0140] At step 538, the transmitting computer 108 may provide an authorization response message to the resource provider computer 106.

[0141] At step 540, after receiving the authorization response message from the transmitting computer 108, the resource provider computer 106 may provide the user equipment 102 with the authorization response message and / or an indication of whether the interaction is authorized. Upon receiving the authorization response message, the resource provider computer 106 may identify the source of funds used in the interaction based on the source of funds data included in the authorization response message by the authorizing entity computer 112.

[0142] In some implementations, a user of user equipment 102 can perform interactions with the resource provider of operating resource provider computer 106. This interaction could be a transaction in which the user obtains a specific resource from the resource provider. Transport computer 108 can access user rules and resource provider rules that may affect the processing of the interaction. For example, transport computer 108 can use API calls to obtain one or more user rules for the interaction from a user rules database, which is maintained by transport computer 108, network processing computer 300, or authorized entity computer 112.

[0143] In some implementations, the transfer computer 108 may acquire and store a set of user rules associated with the credentials for application to the interaction. The transfer computer 108 may determine a subset of user rules from the set of user rules associated with the credentials, determine a subset of resource provider rules based on the subset of user rules, and apply the subset of user rules and the subset of resource provider rules to the transaction.

[0144] The implementation of this disclosure offers several advantages. For example, it reduces network bandwidth and latency. It reduces the number of real-time messages currently available in the ecosystem that support user-selective purchases, messages that involve high bandwidth and capacity while increasing latency.

[0145] The implementation offers additional advantages. For example, it reduces credential issuance workload, fraud, and computational resources required for authentication. It reduces the workload associated with physically and digitally issuing multiple credentials to users, while simultaneously reducing fraud and authentication efforts within the network.

[0146] The implementation plan provides technical improvements to data privacy and reduces fraud. For example, by switching between flexible credentials and genuine credentials, genuine credentials can not only be used for (e.g.) Figure 1 The system maintains confidentiality regarding the computers and devices present, and also prevents leakage in the event of a man-in-the-middle attack. Due to flexible credentials, the exposure of genuine credentials is minimized. As another example, genuine credentials can be kept confidential from resource providers during interactions.

[0147] The implementation plan offers additional advantages. For example, it reduces redundant development work. It also reduces future network and ecosystem development efforts, allowing for the continuous introduction / use of new funding sources (such as cryptocurrencies, points, etc.) without significant network and ecosystem changes.

[0148] Although the steps in the flowcharts and process flows described above are shown or described in a specific order, it should be understood that embodiments of the invention may include methods with steps in a different order. Furthermore, steps may be omitted or added, and these steps may still be within the scope of embodiments of the invention.

[0149] Any software component or function described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C#, Objective-C, Swift, or a scripting language such as Perl or Python, employing techniques such as conventional or object-oriented methods. The software code may be stored as a series of instructions or commands on a computer-readable medium for storage and / or transmission. Suitable media include random access memory (RAM), read-only memory (ROM), magnetic media such as hard disk drives or floppy disks, or optical media such as optical discs (CDs) or digital versatile discs (DVDs), flash memory, and the like. The computer-readable medium may be any combination of such storage or transmission devices.

[0150] Such programs can also be encoded and transmitted using carrier signals adapted for transmission over wired, optical, and / or wireless networks conforming to various protocols, including the Internet. Therefore, computer-readable media according to embodiments of the invention can be created using data signals encoded with such programs. Computer-readable media encoded with program code can be packaged with compatible devices or provided separately from other devices (e.g., downloaded via the Internet). Any such computer-readable medium can reside on or within a single computer product (e.g., a hard disk drive, CD, or an entire computer system) and can exist on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing a user with any of the results mentioned herein.

[0151] The above description is illustrative and not restrictive. Many variations of the invention will become apparent to those skilled in the art upon reading this disclosure. Therefore, the scope of the invention should not be determined by reference to the above description, but rather by reference to the pending claims and their full scope or equivalents.

[0152] Without departing from the scope of the invention, one or more features of any embodiment may be combined with one or more features of any other embodiment.

[0153] As used herein, unless explicitly indicated otherwise, the terms “a,” “an,” or “the” are intended to mean “at least one.”

Claims

1. A method comprising: The server computer receives an authorization request message from a resource provider computer operated by the resource provider. The authorization request message includes flexible credentials and amounts for a transaction between the user and the resource provider, and the flexible credentials are associated with multiple sources. The server computer determines a subset of the user rules to be applied to the transaction from the set of user rules associated with the flexible credential; The server computer determines the subset of resource provider rules for the resource provider based on the subset of user rules to be applied to the transaction; as well as The server computer applies the subset of user rules and the subset of resource provider rules to the transaction.

2. The method of claim 1, wherein the server computer is a network processing computer or a transmission computer.

3. The method of claim 1, wherein the subset of user rules includes using a card of the first type for the transaction, and the subset of resource provider rules includes using a first network processing computer of a plurality of network processing computers to process the transaction.

4. The method of claim 1, wherein the machine learning model determines the subset of user rules and the subset of resource provider rules.

5. The method of claim 1, wherein determining the subset of user rules in the set of user rules associated with the flexible credential comprises: The server computer uses the flexible credentials to identify the subset of user rules in the user rules database.

6. The method of claim 1, wherein the flexible credential includes a flexible account issuer identifier corresponding to the authorizing entity.

7. The method of claim 1, further comprising: The server computer provides an identification table to the resource provider computer, wherein the identification table includes a range of one or more types of account issuer identification numbers that identify account issuer identification numbers.

8. The method of claim 7, wherein the resource provider computer uses the identification table to identify the flexible credential as corresponding to a flexible account issuer identifier, determines one or more resource provider rules for the transaction based on the flexible account issuer identifier, and includes the one or more resource provider rules in the authorization request message.

9. The method of claim 1, wherein the authorization request message further comprises one or more resource provider rules, and wherein determining the subset of resource provider rules includes: The server computer selects the subset of resource provider rules from the one or more resource provider rules using a subset of user rules.

10. The method of claim 1, wherein applying the subset of user rules and the subset of resource provider rules to the transaction comprises: The server computer routes the authorization request message to the alternative network processing computer.

11. The method of claim 1, wherein applying the subset of user rules and the subset of resource provider rules to the transaction comprises: The server computer modifies the authorization request message based on the subset of user rules to include an indication of a source among the plurality of sources.

12. The method of claim 1, further comprising: The server computer removes the flexible credential from the authorization request message; as well as The server computer includes the real credential, in place of the flexible credential, in the authorization request message.

13. The method of claim 1, wherein determining the subset of user rules comprises: The server computer generates a user rule request message that includes the flexible credentials; The server computer provides the user rule request message to the authorized entity computer, wherein the authorized entity computer determines the subset of user rules based on the set of user rules stored in the user rule database associated with the flexible credential; as well as The server computer receives a user rule response message, which includes the subset of user rules, from the authorized entity computer.

14. A server computer, comprising: processor; and A computer-readable medium coupled to the processor, the computer-readable medium including code executable by the processor to implement a method comprising: Receive an authorization request message from a resource provider computer operated by the resource provider. The authorization request message includes flexible credentials and amounts for a transaction between the user and the resource provider, the flexible credentials being associated with multiple sources. Determine a subset of the user rules to be applied to the transaction from the set of user rules associated with the flexible credential; The subset of resource provider rules for the resource provider is determined based on the subset of user rules to be applied to the transaction; and The subset of user rules and the subset of resource provider rules are applied to the transaction.

15. The server computer of claim 14, wherein the server computer is a network processing computer storing an identifier table and a user rules database, wherein applying the subset of user rules and the subset of resource provider rules to the transaction comprises: The authorization request message is modified based on the subset of user rules to include an indication of the source among the plurality of sources; The alternative network processing computer is determined based on the subset of the resource provider rules; as well as The authorization request message is provided to the alternative network processing computer.

16. The server computer of claim 14, wherein the server computer is a transmission computer storing an identifier table and a user rules database, wherein applying the subset of user rules and the subset of resource provider rules to the transaction comprises: The authorization request message is modified based on the subset of user rules to include an indication of the source among the plurality of sources; The network processing computer is determined based on the subset of the resource provider rules; as well as The authorization request message is provided to the network processing computer.

17. The server computer of claim 14, wherein the user rules in the subset of user rules indicate a source among the plurality of sources.

18. The server computer of claim 14, wherein the flexible credential is a token, the server computer is a network processing computer, and wherein the method further comprises: The token is provided to a token service provider computer, wherein the token service provider computer determines the account associated with the token; as well as The account is received from the computer of the token service provider.

19. A method comprising: A resource provider computer receives flexible credentials from a user device for transactions between the user and the resource provider, wherein the resource provider computer is operated by the resource provider, and wherein the flexible credentials are associated with multiple sources. The resource provider's computer uses an identification table to identify the flexible credentials as associated with multiple sources; The resource provider's computer determines one or more resource provider rules for the transaction; The resource provider's computer generates an authorization request message for the transaction, wherein the authorization request message includes the flexible credential and the amount; as well as The resource provider computer provides the authorization request message and one or more resource provider rules to the transmitting computer to request authorization for the transaction.

20. The method of claim 19, further comprising: The resource provider's computer receives the selected user rules from the user equipment; as well as The selected user rules are provided by the resource provider computer to the transmitting computer.