Computer-implemented method for data processing in screened expenditure plans

Abstract

Systems and methods for data processing, data verification, and item classification are disclosed. The method includes receiving a request from a first subsystem, wherein the request includes a plurality of data associated with an access device. It is determined that the first subsystem and / or the access device has authorization to access a service. Contextual data of one or more wallets associated with the access device and / or a state of the first subsystem are determined, wherein the contextual data includes expiration dates and / or rules associated with the one or more wallets. Based on the context data and / or the state of the first subsystem, the request is transmitted to a second subsystem for classifying one or more items associated with the request into one or more categories. The request is executed based on one or more categories.

Description

[0001] Cross-reference to related applications

[0002] This patent application claims the benefit of priority to U.S. non-provisional application No. 18 / 449,058, filed August 14, 2023, and U.S. provisional application No. 63 / 489,955, filed March 13, 2023, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure generally relates to the field of data processing, and more specifically to systems and methods for performing certified and screened electronic transactions. Background Technology

[0004] Current electronic transaction systems and services face the challenge of tracking, analyzing, and / or categorizing permitted product items associated with various prepaid benefits plans. Existing systems and services also experience technical difficulties in allowing selected users to access funds after wallets holding cash or virtual value for a benefits plan expire. The increasing use of alphanumeric Merchant Identifier (MID) numbers has led to a rising rate of false matches, and current technology is limited in its ability to efficiently and accurately detect false matches. A system is also needed that adjusts the order of wallet usage for sub-plans within certain acceptable alternatives, including prohibiting additional users of benefits accounts from using certain wallets. Existing technologies face technical challenges in pre-defining acceptable alternative priorities for sub-plans or cardholders / users, which poses challenges in restricting access to prevent abuse. This disclosure aims to address these and other shortcomings of existing electronic transaction systems and services.

[0005] Unless otherwise stated herein, the materials described in this section are not prior art to the claims of this application and are not acknowledged as prior art or suggestions of prior art by virtue of their inclusion in this section. Summary of the Invention

[0006] This disclosure addresses this problem and / or other problems described above or elsewhere in this disclosure by authenticating the access device and / or merchant system and determining its contextual data for classifying items associated with a transaction request, and improves the state of conventional data processing methods.

[0007] In some embodiments, a system for data processing, data verification, and item classification is disclosed. The system includes: one or more processors; and at least one non-transitory computer-readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: receiving a request from a first subsystem, wherein the request includes multiple data associated with an access device; determining that the first subsystem, the access device, or a combination thereof is authorized to access the service; determining context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes expiration dates of the one or more wallets, one or more rules associated with the one or more wallets, or a combination thereof; transmitting the request to a second subsystem, at least in part based on the context data, the state of the first subsystem, or the combination thereof, for classifying one or more items associated with the request into one or more categories; and executing the request based on the one or more categories.

[0008] In some embodiments, a computer-implemented method for data processing, data verification, and item classification is disclosed. This computer-implemented method includes: receiving a request from a first subsystem by one or more processors, wherein the request includes multiple data associated with an access device; determining by the one or more processors that the first subsystem, the access device, or a combination thereof are authorized to access the service; determining by the one or more processors context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes expiration dates of the one or more wallets, one or more rules associated with the one or more wallets, or a combination thereof; transmitting the request to a second subsystem by the one or more processors, at least in part, based on the context data, the state of the first subsystem, or the combination thereof, for classifying one or more items associated with the request into one or more categories; and executing the request by the one or more processors based on the one or more categories.

[0009] In some embodiments, a non-transitory computer-readable medium for data processing, data verification, and item classification is disclosed. The non-transitory computer-readable medium stores instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: receiving a request from a first subsystem, wherein the request includes multiple data associated with an access device; determining that the first subsystem, the access device, or a combination thereof is authorized to access the service; determining context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes expiration dates of one or more wallets, one or more rules associated with one or more wallets, or a combination thereof; transmitting the request to a second subsystem, at least in part based on the context data, the state of the first subsystem, or the combination thereof, for classifying one or more items associated with the request into one or more categories; and executing the request based on the one or more categories.

[0010] It should be understood that the foregoing general description and the following detailed description are merely exemplary and illustrative, and do not limit the detailed implementations as claimed. Attached Figure Description

[0011] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate several embodiments and, together with the specification, serve to explain the principles of this disclosure.

[0012] Figure 1 The diagram illustrates an example of a system capable of authenticating access devices and / or merchant systems for classifying items associated with a transaction request, based on various aspects of this disclosure.

[0013] Figure 2 The transaction process is illustrated in accordance with the various aspects of this disclosure.

[0014] Figure 3 Detailed exemplary illustrations of classification systems according to various aspects of this disclosure are provided.

[0015] Figure 4 This is a flowchart illustrating, according to various aspects of this disclosure, a process for authenticating access devices and / or merchant systems and determining their contextual data for classifying items associated with a transaction request.

[0016] Figure 5 An exemplary machine learning training flowchart is shown.

[0017] Figure 6 An example is given of how a computer system implements the techniques presented in this article. Detailed Implementation

[0018] While the principles of this disclosure have been described herein with reference to exemplary embodiments for particular applications, it should be understood that this disclosure is not limited thereto. Those skilled in the art and those who access the teachings provided herein will recognize that additional modifications, applications, embodiments, and equivalents fall within the scope of the embodiments described herein. Therefore, the invention should not be considered limited to the foregoing description.

[0019] Various non-limiting embodiments of this disclosure will now be described to provide a general understanding of the structure, function, and principles of use of the systems and methods disclosed herein for identifying where, when, and on which items a cardholder or their dependent can use card funds. This includes classifying items associated with authenticated transaction requests in real-time or near real-time and matching them with accessible rule-based wallets based on permitted location, time, and person.

[0020] Various businesses offer their beneficiaries access to prepaid benefits (or funds). For example, government programs (e.g., Medicaid / Medicare, Supplemental Nutrition Assistance Program (SNAP), Special Supplemental Nutrition Program for Women, Infants and Children (WIC), farmers markets, etc.), social programs (e.g., Social Security, Child Support, Housing Programs, etc.), disaster relief programs, insurance companies, manufacturers, and general retailers may each offer prepaid benefits to incentivize the use of their prepaid services. Conventional electronic payment / funds transaction systems technically face the challenge of conveniently tracking, analyzing, and / or classifying pre-approved product items associated with various combinations of benefit programs accessed from a single card account.

[0021] Typically, benefits have a limited expiration date, with each benefit associated with a wallet that has a valid expiration date (e.g., an e-wallet belonging to an access device that holds a certain amount of value, cash, or virtual value of the benefit plan). In some cases, preventing a user (e.g., a cardholder) from accessing funds at their expiration date can prevent access to funds that may have already been credited or to purchases that may have been requested near or after the wallet's expiration date. For example, a merchant might mistakenly charge a user twice for a single transaction and then credit the overcharged amount to the wallet associated with the user near or after the wallet's expiration date. Because the wallet has expired, the amount or benefits associated with that amount cannot be accessed. Granting selected users the ability to access funds after the wallet's default expiration date is technically challenging for current electronic payment / funds transaction systems, as not all users are affected. Furthermore, issuing separate cards or creating separate wallets on existing cards to transfer overcharged amounts presents reconciliation issues for benefit providers who may need to attribute the funds to the original benefit period, and this could become unsupportable as compliance requirements evolve (e.g., for the Centers for Medicare & Medicaid Services (CMS)). Therefore, current electronic payment / funds transaction systems face the technical challenge of providing a method that allows selected users to access funds for an additional period of time. For example, one approach supports service restoration for creditworthiness after the normal program validity period of benefits has ended, and allows users to access funds, such as overcharged amounts, for an additional period of time.

[0022] While benefit plans are designed to form a standard set of rules for most recipients, these rules are not always one-size-fits-all. They typically need to be based on the user's specific needs for effective use of available funds, rather than rigid plan rules that unintentionally prevent users from accessing available funds. For example, plan rules might require a user to use funds in their food wallet and then use rewards funds. However, if rewards funds are set to expire, a user might prefer to use rewards funds before using funds in their food wallet (e.g., for purchasing food). Service providers (e.g., current electronic payment / funds transaction systems) technically face the challenge of pre-defining an acceptable set of alternative priorities that users can choose. A system is needed to change the order of use of sub-plans (e.g., plans) within certain acceptable alternatives. There are also requirements to restrict access to wallets to prevent abuse when multiple users (especially minors) are associated with a primary account number (PAN). Sub-account users (e.g., minors) should not use certain benefits associated with that account. For example, employer-provided transportation benefits and / or Health Savings Accounts (HSAs) are only for primary cardholders and should not be accessible to sub-account users at will.

[0023] Current electronic payment / funds transaction systems face technical challenges in updating merchant matching logic to prevent erroneous matches, a situation exacerbated by the increasingly stringent requirements of Filtered Spending (FS) plans. Two fundamental reasons exist: inaccurate matching and the growth of retailers (at the store level). With the increasing use of alphanumeric Merchant Identifier (MID) numbers by merchant acquiring institutions, any current process utilizing the merchant list exacerbates the frequency of erroneous matches with the service provider's merchant list, whether for inclusion, exclusion, remapping, exception handling, or other capabilities. This merchant list is normalized to replace non-numeric characters with 0s to support merchant number ranges. For example, MIDs ABC123, XYZ123, 0-0123, etc., are treated as 000123 (if they are 000123). While this approach allows defining merchant ranges in a single configuration instead of having to specify each MID individually, such ranges are not possible for alphanumeric MIDs. In practice, very few MID ranges are used, making the use of range logic almost irrelevant. Furthermore, due to the complexity of networks, it may be necessary to frequently define new groups of Merchant Class Codes (MCCs) that allow transactions. An improved method is needed to match merchant IDs for all merchant lists used in the plan.

[0024] Furthermore, as retail groups expand their stores through mergers, acquisitions, or organic growth, complaints about missing matches have been increasing. For example, the increase in the number of FS plans has introduced situations where sub-plans (e.g., wallets, purses, etc.) are aligned with retailer partnerships, meaning that all or only certain stores of the retailer should be allowed. The increase in restricted use plans for all stores of a particular merchant group is problematic if MIDs of all applicable stores must be collected, as they will be recorded under each allowed network. However, the acquiring institution names for all these stores typically follow a limited set of variations that are easier to identify, maintain, and facilitate wallet eligibility.

[0025] In general, there has been an increase in programs requiring specialized rules for wallet selection or eligibility based on the location where cardholders transact or redeem their card-based funds and the nature of what they purchase. This necessitates an upgrade to the current MCC grouping and network name functionality used throughout the program for better usability during authorization. A system is needed that: (i) introduces a restricted authorized network (RAN) list with the ability to support the requirements of specialized rules; (ii) reduces manual configuration for establishing new programs with different MCC and network requirements; (iii) improves authorization accuracy to use actual merchant identifiers to qualify wallets for use in transactions; (iv) enhances the ability to support networks of all “Retailer Name” merchants without requiring the maintenance of separate lists of MIDs; and / or (v) allows them to purchase pre-approved / permitted product items with card funds.

[0026] To address these technical challenges Figure 1 Advanced data processing, data validation, and data filtering capabilities are applied to methods and systems to authenticate access devices and / or merchant systems and determine their contextual data for classifying items associated with transaction requests. Figure 1 An exemplary architecture of one or more exemplary embodiments of the present invention may include a system 100, which includes an access device 101, a point-of-sale (POS) terminal 103, a merchant system 105, an acquiring institution system 107, a transaction network 109, an issuing institution system 111, and an exchange system 113 (i.e., a filtered transaction processing system) connected to a rules engine 115 and a data processing platform 117. The rules engine 115 and the data processing platform 117 may use information derived from messages from the POS terminal 103 and the merchant system 105, which is delivered to the issuing institution system 111 via the transaction network 109.

[0027] System 100 can apply sophisticated data processing, verification, confirmation, and filtering technologies to track, analyze, and / or categorize pre-approved product items associated with various prepaid benefit plans in real-time or near real-time. System 100 can provide an advanced method that allows users to access their funds after the normal maturity of wallets holding cash or virtual value for a benefit plan. System 100 can also provide enhanced authentication mechanisms to efficiently and accurately detect false matches, preventing them due to the use of alphanumeric MID numbers and / or the use of merchant names. System 100 can implement sophisticated logic to predefine a set of acceptable alternative priorities for sub-plans and modify the wallet usage order for specific card accounts within acceptable alternatives. System 100 can generate rules specific to wallets with multiple users and prevent wallet abuse by restricting access to some wallets by additional users of an account. System 100 can also provide an improved method for matching merchant IDs, reducing the need to frequently define new MCC groups due to network complexity. In this way, System 100 can address the technical shortcomings of existing electronic transaction systems and services.

[0028] In one implementation, access device 101 may be a screened transaction carrier. The screened transaction carrier may be, for example, a credit card, debit card, gift card, membership card, loyalty card, contactless payment device, digital payment device, digital wallet, etc. The screened transaction carrier can be used in any location (e.g., physical stores, online e-commerce websites, e-commerce applications, etc.), where the sponsoring network of the screened transaction carrier (e.g., New York Money Exchange (NYCE), Visa®, MasterCard®, Discover®, other regional networks, etc.) may be accepted. In one implementation, access device 101 may include one or more user sub-accounts (e.g., wallets, etc.) funded by participating entities (e.g., merchants, banks, corporations, government agencies, etc.). Access device 101 may be used at one or more merchant stores, online websites, or applications that can be associated with screened transaction carriers issued by one or more participating entities (e.g., sponsoring or funding entities). In one implementation, the screened transaction carrier may include the functionality and aspects of both screened and non-screened transaction carriers (e.g., a standard credit card or debit card). In other words, the selected transaction carrier can be used anywhere that is accepted, whether it is a selected transaction carrier or a standard credit or debit card. In another scenario, in addition to item selection, all the options described in this article can be used to process non-selected transactions.

[0029] In one implementation, POS terminal 103 can be a traditional POS, an electronic cash register (ECR), or any mobile communication device (e.g., a handheld computer, desktop computer, laptop computer, wireless communication device, mobile phone, smartphone, mobile communication device, personal communication system (PCS) device, tablet computer, server computer, gateway computer, or any electronic device). POS terminal 103 can collect transaction data (e.g., purchase transaction data) associated with access device 101 when a user (e.g., customer, recipient, beneficiary, etc.) submits access to device 101 at POS terminal 103, and can transmit the transaction data associated with access device 101 to merchant system 105, and ultimately to rule engine 115 and / or data processing platform 117.

[0030] In one implementation, POS terminal 103 may be a standalone transaction screening terminal (e.g., a standby terminal / freestanding terminal) or another non-integrated POS terminal that can be configured to accept screening access devices. POS terminal 103 may communicate with merchant system 105 to execute electronic transactions (e.g., purchase transactions) associated with access device 101. Alternatively or additionally, POS terminal 103 may communicate directly with rules engine 115 and data processing platform 117 to execute electronic transactions as disclosed herein. Rules engine 115 and data processing platform 117 may act as intermediaries in the system to ensure the validity of transaction requests associated with access device 101.

[0031] In one implementation, merchant system 105 may include a payment terminal (e.g., a "keypad") or a data server, such as hosting a merchant's e-commerce (or online) store. Alternatively or additionally, merchant system 105 may collect transaction data associated with access device 101 via an online or offline interface and transmit the transaction data to acquiring institution system 107. Acquiring institution system 107 may communicate with issuing institution system 111 via transaction network 109 to execute one or more transactions based on the received transaction data.

[0032] In one embodiment, rule engine 115 is a platform with multiple interconnected components. Rule engine 115 includes one or more servers, intelligent network devices, computing devices, components, and corresponding software for authenticating, overwriting, and / or updating data associated with transaction requests. In one embodiment, rule engine 115 may include comparison module 119, evaluation module 121, update module 123, and machine learning module 125.

[0033] In one implementation, comparison module 119 may perform name matching during authorized settlement by providing the ability to include alphanumeric MIDs in the merchant list in a manner that does not invalidate the current list by: (i) modifying the authorized lookup to determine a match using the actual MID, (ii) normalizing the MID after determining that no match exists and retrying the lookup with the normalized value, or (iii) running a script to look up the most recently approved transactions based on the normalized MID, collecting the original MID values, and performing a comparison. In another implementation, comparison module 119 may extend the current wallet eligibility logic to include merchant name matching logic (e.g., MCC and MID) and the ability to configure the RAN list via Automated Client Configuration (ACC). In an exemplary implementation, comparison module 119 may modify the merchant name matching logic to utilize the RAN list when certifying a wallet based on MID and merchant name. For example, the authorized lookup is changed to first use the RAN logic, and if no match is found, the MID is normalized and the lookup is retried with the normalized value. In one implementation, comparison module 119 can generate a report identifying configured items (e.g., MCC groups, networks, or RAN lists) under the client tree to show the items required for proper management of the program. In one case, authorization system 129 can consider RAN methods for merchant terminal IDs, included / excluded networks, exception lists, and verification rules. In one implementation, comparison module 119 can train a machine learning model via machine learning module 125 to perform name matching during authorization settlement.

[0034] In one scenario, Access Device 101 can be an open revolving transaction carrier accepted as long as its network brand (e.g., Visa®, MasterCard®, Discover®) is recognized; and a closed revolving transaction carrier accepted only by the issuing merchant system. RAN bridges the gap between open and closed access devices by building a restricted merchant participation network in which the transaction carrier can be used without any changes to the acquiring side. In another scenario, RAN allows the use of Access Device 101 to be customized to create unique cardholder service programs. RAN provides control, flexibility, and accuracy for the precise targeting of payment card usage. For example, RAN technology can create sub-networks on open networks (e.g., networks operated by Visa®, MasterCard®, Discover® operators) and can direct spending from open revolving transaction carriers only to selected merchants or merchant groups. In many cases, RAN solutions are used to drive specific cardholder / consumer behaviors, such as incentive programs.

[0035] In one implementation, comparison module 119 may allow one or more clients to use ACC nodes to maintain existing RAN list elements that run parallel to existing account-to-account (A2A) calls used to create and maintain sets of data (e.g., country, MCC, MID, merchant name patterns, etc.). In one case, comparison module 119 may create a single ACC node for RAN list maintenance. This node will specify the list name, list subject (e.g., MCC, MID, merchant name), list type (include / exclude), and appropriate list values ​​based on the subject. Each list is independent, allowing an item to appear once on a given list but on additional lists (providing protection against duplication of items already on a list). In one case, the MCC list may accept 4- or 5-digit MCCs (e.g., to verify MCC values ​​in the list against a mapping table), the MID list may accept alphanumeric IDs available under authorization / settlement rules, and the merchant name list may accept wildcards as prefixes, suffixes, or middle names available under authorization / settlement rules.

[0036] In one implementation, the evaluation module 121 can override the expiration date of the wallet associated with access device 101 with a new expiration date (e.g., a predetermined number of additional days based on the user's context information). The evaluation module 121 can utilize an application programming interface (API) to set an alternative wallet expiration date for a specific PAN and wallet. Alternatively, the evaluation module 121 can remove the override and restore the default. For example, if a user purchases an item at the end of the benefit period and encounters an issue requiring them to return or exchange the item, the refund applies to the original wallet that may have expired. As discussed, reopening expired wallets for every user is impractical, transferring refunds to alternative wallets may not match required wallet usage rules, or transferring refunds to wallets for the next period may violate certain regulatory restrictions by giving a full usage period. Therefore, the evaluation module 121 overrides the wallet's expiration date to extend the usage period of funds by an additional number of days, providing users with extra days to access those funds. In one scenario, the coverage expiry date is based at least in part on historical user data (e.g., payment history, payment defaults, fraudulent activities, etc.), credit rating (e.g., credit history), user profile data (e.g., occupation, salary, debt-to-income ratio, etc.), transaction amount, and so on.

[0037] In one implementation, the evaluation module 121 can train a machine learning model via the machine learning module 125 to cover wallet expiration dates. In an exemplary implementation, the machine learning model can compare and analyze transaction history, card loading patterns, user profile data, and / or transaction amounts to make a decision to cover wallet expiration dates. In one implementation, the evaluation module 121 can be directed to set up A2A and / or batch cover expiration dates. Once the expiration date is covered, the evaluation module 121 can generate a non-monetary report indicating the cover action (e.g., extension of the expiration date) and attaching a specific reason and transaction code for review (e.g., review by a risk manager). Such non-monetary memos are included in the report and data extract. In one implementation, during authorization and settlement, the authorization system 129 can apply an extended PAN wallet expiration date instead of the sub-plan's default wallet expiration date. In another implementation, the authorization system 129 can apply wallet purge logic to purge the later of the PAN wallet expiration date or the sub-plan wallet expiration date. In one scenario, the Customer Service Application (CSA) reflects wallet expiration based on PAN wallet expiration data after reviewing the overwriting or restoration of expired wallets as a memo.

[0038] In one implementation, the evaluation module 121 can perform PAN-level coverage or Card Account Number (CAN)-level coverage for the effective use of available funds or to prevent fund misuse. When a new card account is initially created or a sub-plan is defined, the current configuration of wallet priorities can be set to be applied by default to the PAN / CAN. In one implementation, the evaluation module 121 can reconfigure rules and wallet priorities on the sub-plan to allow up to five alternative priorities (e.g., the default plus options A through E). Individual PAN / CAN holders can choose, via plan administrator 131, to apply one of the five alternative priorities via API (or revert to the default) to change the PAN / CAN priority between the default and the configured alternatives. At the CAN level, replacements and renewals automatically inherit the priority selected by the underlying CAN. The list of PAN / CAN selected priorities is retrieved by the API and included in non-monetary reports and data extracts for auditing. In one implementation, during authorization and settlement, the authorization system 129 can look up the PAN / CAN to determine the appropriate priority settings instead of applying the default wallet priorities (existing logic). While the default priorities include all wallets, for options A through E, some wallets are allowed to be omitted. In one exemplary implementation, if an account has HSA benefits with a five-figure balance, dependents (e.g., minors) on the same account should not have access to the HSA funds, and the options set for the dependent's card will be set (e.g., options A through E) to disallow the use of the HSA wallet. In another exemplary implementation, each wallet may have dual priorities, and these priorities may differ in each set of options. For example, an account may have both HSA benefits and consumer funds. Based on the rules applicable to these funds, the user chooses to first use the HSA funds for medical purposes (e.g., hospital bills) and then, where applicable, utilize other available funds until exhausted, after which the HSA funds can be used to cover any remaining purchases. However, if the user is traveling by air for medical reasons, although the preference is to use transportation-enabled funds for air travel if available, the evaluation module 121 can reconfigure the rules to allow the use of HSA funds because the air travel is for medical purposes.

[0039] In one implementation, the evaluation module 121 can train a machine learning model via the machine learning module 125 to perform PAN / CAN level coverage for the effective use of available funds or to prevent fund misuse. In one exemplary implementation, the machine learning model can analyze the account profiles of users (e.g., primary account holders, secondary account holders) to determine access levels to benefits. In one exemplary implementation, the machine learning model can process transaction types and their purposes to determine wallet priorities.

[0040] In one implementation, update module 123 can update existing wallet-based ACC nodes to apply RAN lists instead of MCC groups (e.g., sets of MCCs) and networks. For example, MCC groups can identify the allowed set of MCCs for a wallet and MCC-specific cash usage restrictions; network names can identify a list of remapped merchants; exclusionary merchant networks can identify up to 10 MID lists to disqualify transactions; and merchant terminal identifier (MTID) networks can identify up to 10 MID lists to prohibit or override to allow. In one implementation, update module 123 can update MCC groups with alternative RAN MCC groups to define the allowed MCCs on the wallet (e.g., providing a set of up to 10 RAN MCC group elements for each occurrence of an MCC group element, which can be inclusive or exclusionary). In one implementation, update module 123 can update network names with alternative RAN network names to define the possible merchants allowed on the wallet (e.g., providing a set of up to 10 RAN network name elements for each occurrence of a network name element, which can be inclusive or exclusionary in nature). In one scenario, excluding a merchant network may not be necessary because the RAN MCC group could be the exclusion type. In another scenario, the MTID network wallet can be compatible with RAN technology. In this way, update module 123 allows alternative methods to define and maintain the MCC group and network name used for wallet eligibility, thereby enabling precise configuration of the scheme to support granular authorization and settlement rules. In one implementation, update module 123 can add sub-scheme identifiers to select merchants containing exclusion qualifiers (MIEQ) instead of traditional target wallet selection. For example, MCCMIEQ replaces the MCC group on the wallet, and MTID MID MIEQ replaces the network. In one implementation, update module 123 can train a machine learning model via machine learning module 125 to update existing wallets.

[0041] During wallet qualification, update module 123 can compare the incoming MCC or MID with the MCC, MID, and merchant name of wallet configurations allowed or prohibited by the one-to-many list. In one implementation, update module 123 can update the target wallet's authorization policy to utilize the RAN list instead of MCC groups or network names. For example, the application for a merchant network wallet and the configuration for including or excluding excluded merchant networks are updated to use the included or excluded RAN list. In one case, wallet qualification based on the included RAN list (e.g., MCC, MID, and merchant name) replaces the previous MCC group and network name logic. As a result, in the absence of excluded merchant networks (effectively deprecated by RAN MCC exclusion) or MTID networks, update module 123 can:

[0042] a. If the transaction MCC is on the RAN MCC list but not on the RAN MCC exclusion list, then the wallet is qualified;

[0043] b. If the transaction MCC is not disqualified based on the RAN MCC list, but is allowed based on a list containing RAN MID or merchant name, then the wallet is qualified.

[0044] c. If a transaction is verified based on the RAN MCC list, but blocked based on the RAN MID and merchant name lists, then the wallet's eligibility will be revoked;

[0045] d. Provide the ability to configure a RAN list that is effectively fully open to the MCC when using MID or merchant name exclusion; and / or

[0046] e. Provides the ability to configure a RAN list that effectively blocks all MCCs unless the MID or Merchant Name RAN list allows their use.

[0047] In another implementation, update module 123 can update the configuration of included or excluded merchant network wallets and excluded merchant networks to use the included or excluded MIEQ list. In one case, the eligibility of wallets based on the included MIEQ list (e.g., MCC, MID, merchant name, and merchant location) replaces the previous MCC group and network name logic. As a result, in the absence of excluded merchant networks or MTID networks, update module 123 can:

[0048] a. If the transaction MCC is on the list of MIEQ MCCs that include MIEQ MCCs but not on the list of excluded MIEQ MCCs, then the wallet is qualified (i.e., equivalent to the logic of existing MCC groups).

[0049] b. If the transaction MCC is not disqualified based on the MIEQ MCC list, but is allowed based on a list containing RAN MID or merchant name, then the wallet is qualified.

[0050] c. If a transaction is verified based on the MIEQ MCC list, but blocked based on the MIEQ MID, merchant name, or merchant location, the wallet's eligibility will be revoked.

[0051] d. Provide the ability to configure a MIEQ list that is effectively fully open to the MCC when using MID or merchant name exclusion; and / or

[0052] e. Provides the ability to configure a MIEQ list that effectively blocks all MCCs unless the MID or Merchant Name MIEQ list allows them.

[0053] The use of remapping networks (e.g., where a MID resides in the network and is associated with an AMCC, which must be verified against the wallet's MCC group for eligibility) has been eliminated. Instead, a wallet can have up to 10 MIDs and 10 merchant name RAN lists. Conceptually, clients using remapping networks define RAN lists organized by valid AMCCs; they can associate RAN lists with wallets as needed, and thus eligible wallets if a merchant appears on the MID or merchant name RAN associated with them. In one case, by using RAN lists for MCC lists, merchant ID lists, and introducing merchant name pattern matching, the complexity of configuring and processing target transactions and the need for frequent manual maintenance are reduced. Furthermore, the data required to support many programs that require special processing based on the "all locations" of merchants is reduced. Additionally, the accuracy of the authorization system 129 is improved by using actual MID numbers.

[0054] In one implementation, update module 123 can generate a report providing RAN list details. This report may include the RAN list name, subject, type configured for wallets (and sub-plans), and / or a list of elements on the RAN list. In one instance, the Customer Service Application (CSA) wallet details provide customers or agents with the opportunity to review transactions against supported MCC, MID, Cash Tracking and Integrated Inventory Approval System (IIAS) categories or Screened Expenditures (FS) categories. In one implementation, update module 123 can update CSA wallet details to display RAN information in the wallet details view. For example, the CSA wallet details MCC page may include the MCC in the MCC inclusion and exclusion indications. For example, the wallet details MID page may be corrected to display the MID number and include the RAN MID number with inclusion / exclusion indications. For example, a new Merchant Name page may be updated to identify the Merchant Name RAN inclusion / exclusion list. For example, a new MTID page may be updated to reflect the MTID configuration. In one instance, the ability to support IIAS or FS category grouping needs to be directly assignable to sub-plans, allowing new combinations to be dynamically set. In one implementation, update module 123 has the ability to create new RAN list topics via ACC nodes, supporting authentication rules based on MCC groups and network-triggered IIAS, FS, or other authentication types.

[0055] In one implementation, the machine learning module 125 uses training data containing inputs and correct outputs (e.g., from...). Figure 5The training data 512 illustrated in the training flowchart 500 is used to train the model, allowing the model to learn over time. When input is fed into the machine learning model, training is performed based on the deviation between the processed results and the recorded results; for example, the algorithm measures its accuracy using a loss function and adjusts until the error has been sufficiently minimized. In one implementation, the machine learning module 125 randomizes the order of the training data, visualizes the training data to identify correlations between different variables, identifies any data imbalances, and splits the training data into two parts, one for training the model and the other for validating the trained model, and performs deduplication, normalization, correction, etc., on errors in the training data. The machine learning module 125 implements various machine learning techniques, such as k-nearest neighbors, Cox proportional hazards models, decision tree learning, association rule learning, neural networks (e.g., recurrent neural networks, graph convolutional neural networks, deep neural networks), inductive programming logic, support vector machines, Bayesian models, etc. In one implementation, the machine learning module 125 can perform complex data analysis, rule and / or predictive modeling on historical data to learn data routing, user authentication, and / or transaction authorization. For example, the machine learning module 125 can identify any violations in regular transactions and user authentication in real time or near real time.

[0056] As used herein, terms such as “module” or “component” generally encompass hardware and / or software, such as processors used to implement associated functions. The modules and components presented above in Rule Engine 115 are implemented in hardware, firmware, software, or a combination thereof. Although in Figure 1 While depicted as a separate entity, it can be expected that the rules engine 115 is also implemented for use by computer system 600 ( Figure 6 Direct operation. Therefore, the rule engine 115 generates direct signal inputs through the operating system of the computer system 600. The various execution methods presented herein anticipate any and all arrangements and models.

[0057] In one implementation, the rules engine 115 can transmit authenticated and updated data to the data processing platform 117. In one implementation, the data processing platform 117 is a platform with multiple interconnected components. The data processing platform 117 includes one or more servers, intelligent network devices, computing devices, components, and corresponding software for screening transactions, allowing participating members to purchase screened items from participating entities. In one implementation, the data processing platform 117 may include a classification system 127 and an authorization system 129.

[0058] In one implementation, the acquiring institution system 107 may include a standalone acquiring institution system and / or an integrated acquiring institution system, which may be configured to receive transaction data from the merchant system 105. The acquiring institution system 107 may receive transaction requests associated with access device 101 from the POS terminal 103 and / or the merchant system 105. Transaction requests may include, for example, requests to authorize a purchase / payment transaction. The acquiring institution system 107 may then determine whether the access device 101 is a screened or unscreened transaction carrier. The acquiring institution system 107 may communicate with the issuing institution system 111 and the transaction network 109 to complete the transaction request.

[0059] In one implementation, the exchange system 113 can determine whether a transaction request includes enhanced data, simplified enhanced data, or non-enhanced data. In one implementation, enhanced data may include, for example, inventory unit (SKU) level data (i.e., UPCs used for generic product codes, also known as complete shopping cart data). An SKU is a unique identifier for an item sold or offered by a merchant or selected transaction participant entity. In some implementations, enhanced data may be required to facilitate the selected transaction process of this disclosure. In one case, if the transaction request includes simplified or non-enhanced data, the exchange system 113 may transmit the transaction request to the authorization system 129 to complete the transaction. In another case, if the transaction request includes enhanced data (e.g., SKU-level data), the exchange system 113 may transmit the transaction request with enhanced data to the classification system 127.

[0060] In one implementation, classification system 127 can analyze and / or classify transaction data associated with (e.g., contained therein) a received transaction request. In one implementation, classification system 127 includes an Approved Product List (APL) database 229 and a classification engine 231, which will be discussed below. Figure 2 The following discussion will cover this. In one implementation, following the exchange system 113, the acquiring institution system 107 can be connected to the issuing institution system 111 via the transaction network 109, which in turn transmits transaction requests to the classification system 127 and / or the authorization system 129. The classification system 127 then transmits the analyzed and / or classified transaction data to the authorization system 129 via the exchange system 113. The authorization system 129 then transmits the issuing institution system 111's response via the transaction network 109 to complete the transaction request, as discussed in detail below.

[0061] Figure 2 Example 200 illustrates a transaction process selected according to various aspects of this disclosure. Figure 2Exemplary illustrations depicting system 100 in more detail are provided but should not be construed as limiting system 100. In one embodiment, merchant system 105 may include participating merchant system 201, self-categorizing merchant system 203, and / or non-participating merchant system 205. In step 207, participating merchant system 201 may utilize a separate screening transaction terminal (e.g., a standalone terminal) or other integrated POS terminal that may be configured to accept the screening of this disclosure. For example, participating merchant system 201 may utilize the integrated acquiring system 209 of acquiring system 107 or a standalone acquiring system 211 to use primary network 215 to transmit enhanced data for screening expenditures to issuing system 111. At issuing system 111, exchange system 113 may be connected to data processing platform 117, which uses data from rule engine 115 to facilitate one or more electronic transactions (e.g., purchase transactions) of this disclosure. In one scenario, a non-participating merchant system 205 can typically use a POS terminal 103.

[0062] In step 213, the acquiring institution system 107 can determine whether to transmit the transaction request via primary network 215 or secondary network 217. For example, if the transaction data includes enhanced data (e.g., SKU-level data), the acquiring institution system 107 can transmit the transaction request to primary network 215 (e.g., the NYCE network). At step 219, primary network 215 can then transmit the transaction request with the enhanced data to switching system 113. If the transaction data does not include any enhanced data, the acquiring institution system 107 can transmit the transaction request via primary network 215 (e.g., the NYCE network) or secondary network 217 (e.g., Visa®, MasterCard®, Discover®, other regional networks, etc.). At step 221, secondary network 217 can directly transmit the transaction request without enhanced data to authorization system 129 to complete the transaction request without routing the transaction request to switching system 113.

[0063] In another embodiment, according to this disclosure, the self-classifying merchant system 203 can communicate with the acquiring institution system 107 to facilitate one or more electronic transactions (e.g., purchase transactions). In one embodiment, the self-classifying merchant system 203 can request participation in one or more aspects of the screening process of this disclosure. However, the self-classifying merchant system 203 may not be configured to transmit the required enhanced data (e.g., SKU-level data) through the acquiring institution system 107. In this embodiment, the self-classifying merchant system 203 may transmit self-classified data (or streamlined enhanced data) along with the transaction request to the acquiring institution system 107. The self-classified data may be data classified by the self-classifying merchant system 203, corresponding to one or more items carried or provided by the self-classifying merchant system 203. The self-classified data may include one or more screened items, which may correspond to category data stored in the classification system 127. In step 213, the acquiring institution system 107 may transmit the transaction request including the self-classified data to the primary network 215 (e.g., the NYCE network) or the secondary network 217 (e.g., the MasterCard network). The primary network 215 or the secondary network 217 can then transmit the transaction request, which includes self-classified data, to the exchange system 113 (step 219) or the authorization system 129 (step 221), and then complete the transaction request with the issuing institution system 111.

[0064] As previously discussed, the exchange system 113 can determine whether a transaction request received from the primary network 215 includes enhanced data, simplified enhanced data, or non-enhanced data. At step 225, the exchange system 113 can determine whether the transaction request includes simplified enhanced data or non-enhanced data, and can transmit the transaction request to the authorization system 129 to complete the transaction request with the issuing institution system 111. At step 227, the exchange system 113 can determine that the transaction request includes enhanced data (e.g., SKU-level data), and can transmit the transaction request with enhanced data to the classification system 127. In one embodiment, the classification system 127 may include an Approved Product List (APL) database 229 and a classification engine 231. The APL database 229 may store one or more APL lists associated with access device 101 (e.g., filtered transaction cards) and / or one or more filtered transaction participants (e.g., banks, corporations, government agencies, etc.). The APL database may have obtained product inventory from participating merchant system 201 or self-classifying merchant system 203 to enable the classification of received enhanced data.

[0065] In one implementation, classification system 127 can manage the contents of an APL list stored in APL database 229. The APL list may include, for example, approved Universal Product Codes (UPCs), Price Lookup Unit (PLU) codes, comparable product identifiers (e.g., manufacturer codes), and / or cross-references to product categories identified by system 100. Participating merchants or any transaction participants in the screening process can add or remove screened items from the APL list based on changes in inventory items via one or more interfaces. In one implementation, a single item may be associated with a single category on a given APL list. Furthermore, the Bank Card Identifier (BIN) of a screened transaction vehicle (e.g., access device 101) may be associated with one or more specific APL lists. Classification system 127 may also provide one or more APL lists to merchants who may request self-classification and / or organization of classification data. In one implementation, classification system 127 may be configured to provide one or more APIs that can be utilized by one or more merchants or entities that may participate in the screening transaction process of this disclosure. One or more APIs can be configured to respond to user queries (e.g., by scanning a UPC code for an item identifier via a client, or by using the API to check if an item has been screened in a transaction process covered by a client application). In one embodiment, one or more APIs can enable the display of graphical primitives, such as icons, bar charts, menus, buttons, data input fields, etc. In another embodiment, one or more APIs can enable an interactive interface for onboarding information to include at least one or more annotations, audio messages, video messages, or a combination thereof. In an exemplary embodiment, one or more APIs operate in conjunction with augmented reality (AR) processing techniques, in which various applications, graphical elements, and features interact.

[0066] At step 227, classification engine 231 may receive a transaction request from exchange system 113 and classify one or more items identified in the transaction request. Classification engine 231 can identify category and subcategory values ​​associated with one or more items identified in the transaction request by checking against the appropriate APL file associated with the specific screened access device 101 of the transaction request. In one embodiment, the APL file may have already grouped items into multiple benefit categories because the screened transaction carrier (e.g., access device 101) may have one or more available benefits, so the grouped categories determined by classification system 127 (by authorization system 129) can be used to determine the most correct placement of those items.

[0067] In one implementation, classification engine 231 may associate the correct APL file for the transaction using identification data (e.g., BIN value or card identifier) ​​of the filtered transaction carrier, where the APL is a list of one or more items (e.g., UPC / PLU items) against which the items identified in the transaction request can be evaluated. Classification engine 231 can then determine a category or subcategory for each UPC / PLU item identified in the transaction request. Classification engine 231 may then create a summary of the total amount allocated across one or more identified categories and provide this information for authorization system 129 to use when identifying the type of benefit wallet (e.g., HFC wallet, OTC wallet, and / or OTH wallet) that can cover that portion of the transaction. In one implementation, classification engine 231 may categorize and summarize items not identified in the APL list into a general category that represents other items not permitted by the APL and, for that instance, only covered by wallets capable of implementing non-APL items (e.g., OTH wallets). Furthermore, in the event of any error associated with the classification process of this disclosure, all identified amounts may be classified into the same generic category representing other items not permitted by APL, since classification may not have occurred.

[0068] After completing step 227, classification system 127 can transmit the classification result to exchange system 113, which can then provide the classification information to authorization system 129 by initiating step 225. That is, classification system 127 can generate a classification response based on one or more items of a transaction request classified by classification engine 231, and authorization system 129 can determine which benefit amount (if any) can be applied. For example, personal benefits are described by one or more public and internal mapping categories, which use data provided in rules engine 115 to correspond to Health Food Choice (HFC) wallets, Over-the-Counter (OTC) wallets, Combinations of these (CMB) and / or other (OTH) wallets. Of course, any other suitable wallets can be identified and established based on products and items associated with transactions that may participate in the screening or with merchants or entities that fall outside the set of merchants available or required for the screening (MCC). One or more benefit wallets may include pre-charged balances provided by sponsoring entities of the transactions screened by this disclosure. Authorization system 129 can use the data provided by classification engine 231, along with wallet definition and rule data, to determine the most suitable set of wallets for the transaction. Therefore, according to this disclosure, one or more wallets (if funded) associated with a screened transaction vehicle can be used to purchase various items that may be eligible or ineligible for the screened transaction.

[0069] At step 230, the authorization system 129 may communicate with the issuing institution system 111 to complete the transaction request initially transmitted from the merchant system 105. For example, based on the classification of items identified in the transaction request, the prepaid balance associated with the screened transaction carrier may be deducted or updated accordingly. The screened transaction process of this disclosure may provide participants such as employers, consumer brands, healthcare institutions, or insurance companies with a means to incentivize payment for specific purchases. That is, beneficiaries (e.g., cardholders) may use screened transaction carriers (e.g., prepaid cards) to purchase items such as, for example, over-the-counter medications (e.g., cough syrup, aspirin, bandages, etc.) as part of a company benefit or consumer brand incentive. Other use cases may include specific health food options that allow cardholders to receive discounts on specific purchases that contribute to overall health. Furthermore, at step 233, the classification system 127 may allow participating entities to classify screened items into categories, update categories in the APL file, track individual product items identified in the transaction request, and report and analyze the screened items listed in the APL file and the associated transaction request. In one implementation, SKU-level data in the enhanced data of transaction requests can be used to identify and update filtered items in the APL file. In some cases, the program administrator can manage the content of APL items and also report on purchased items.

[0070] Figure 3 Detailed exemplary illustrations of classification system 127 are provided, but should not be construed as limiting classification system 127 or system 100. Figure 2 As discussed herein, classification system 127 may include APL database 229 and classification engine 231. Classification system 127 may be communicatively connected to APL interface 301 and PLU / UPC database interface 303.

[0071] In one implementation, classification engine 231 may include one or more servers. For example, in system 300, classification engine 231 may include routing server 305 and processing server 307. In one implementation, routing server 305 may route classification requests (or transaction requests) received from exchange system 113 to processing server 307. In one implementation, processing server 307 may classify one or more items (e.g., data elements 105 to 108 from ISO 8583) associated with the classification request to identify category and subcategory values ​​associated with the one or more items of the classification request by checking against an appropriate APL file. Processing server 307 may communicate with routing server 305 and APL database 229 to perform operations as described above. Figure 2 The process of classifying is performed in process 200.

[0072] In one implementation, APL interface 301 can be configured to communicate with classification system 127 to access one or more APL files in APL database 229. APL interface 301 can be provided as an application or a web service. In one implementation, APL interface 301 can display graphical primitives such as icons, bar charts, menus, buttons, data input fields, etc. In another implementation, one or more APIs can make an interactive interface for guiding information include at least in part one or more annotations, audio messages, video messages, or a combination thereof. In an exemplary implementation, one or more APIs operate in conjunction with augmented reality (AR) processing techniques, where various applications, graphical elements, and features interact. APL interface 301 can allow users, merchants, or customers to access APL files to check whether a specific item or product is supplied or offered by a selected trading participant (e.g., a supplier, employer, consumer brand, healthcare institution, insurance company, etc.).

[0073] In one embodiment, the PLU / UPC database interface 303 may be configured to communicate with the classification system 127 to access one or more APL files, including PLU / UPC data associated with items or products provided by selected trading participants of this disclosure. For example, selected trading participants (e.g., suppliers, employers, consumer brands, healthcare institutions, insurance companies, etc.) may utilize the PLU / UPC database interface 303 to review, track, and / or update UPC / PLU data. For example, selected trading participants may add or update information associated with UPC / PLU items (e.g., descriptions of entries such as nutritional information, images, dimensions, etc.). In one embodiment, the PLU / UPC database interface 303 may display graphical primitives such as icons, bar charts, menus, buttons, data input fields, etc. In another embodiment, one or more APIs may enable an interactive interface for guiding information to include at least one or more annotations, audio messages, video messages, or combinations thereof.

[0074] Figure 4 This is a flowchart of process 400 for authenticating access devices and / or merchant systems and determining their context data for classifying items associated with a transaction request, according to various aspects of this disclosure. In various embodiments, a rules engine 115 and / or a data processing platform 117 may execute one or more portions of process 400 and use, for example, methods including... Figure 6The processor and memory chipset shown are used for implementation. Therefore, the rule engine 115 and / or data processing platform 117 provide means for completing the various parts of process 400, as well as means for combining other components of system 100 to complete other implementations of the processes described herein. Although process 400 is illustrated and described as a series of steps, it is contemplated that various implementations of process 400 can be performed in any order or combination, and it is not necessary to include all illustrated steps.

[0075] In step 401, the issuing institution system 111 may receive a request (e.g., a transaction request) from the first subsystem (e.g., merchant system 105) via processor 602. This request may include multiple data associated with access device 101 (e.g., transaction data or any related data), the status of merchant system 105 (e.g., participating merchant system, self-categorized merchant system, or non-participating merchant system), or the data type (e.g., enhanced data, simplified enhanced data, or non-enhanced data). The transaction request is transmitted by exchange system 113 to data processing platform 117 based at least in part on the attributes of the transaction data.

[0076] In step 403, the data processing platform 117, via processor 602, can utilize transaction data and data from the rule engine 115 to determine whether the merchant system 105 and / or access device 101 are authorized to access services (e.g., filtered consumer services, access to funds associated with a transaction carrier, etc.). In one embodiment, the rule engine 115 can authorize the merchant system 105 and / or access device 101 by configuring a RAN list, wherein the RAN list includes at least one of the following: RAN MCC, RAN MID, or RAN network name. The rule engine 115 can compare the transaction MCC, transaction MID, or transaction merchant system with the RAN MCC, RAN MID, or RAN network name to determine a match. The rule engine 115 can authenticate one or more wallets after determining that the transaction MCC, transaction MID, or transaction merchant system has been approved by the RAN MCC, RAN MID, or RAN network name, respectively. In another embodiment, the rule engine 115 can normalize the transaction MID after determining an unsuccessful match. The rule engine 115 can use the normalized MID to authenticate the merchant system. In one implementation, the data processing platform 117 uses data from the rules engine 115 to disqualify any wallet determined to be unacceptable for transactions, based on MCC, transaction MID (actual or normalized), or RAN or MIEQ configuration.

[0077] In step 405, the data processing platform 117 uses data from the rules engine 115 via the processor 602 to determine context data of one or more wallets associated with the access device 101 and / or the state of the merchant system 105. This context data may include the expiration dates of one or more wallets and / or one or more rules associated with those wallets. In one embodiment, the rules engine 115 may monitor one or more wallets to detect amounts credited to one or more wallets near or after their expiration dates. The rules engine 115 may override the expiration dates of one or more wallets to set alternative expiration dates for accessing the credited amounts, wherein the alternative expiration dates are based on a predetermined duration.

[0078] In another implementation, rule engine 115 can identify one or more subordinate accounts linked to a master account associated with one or more wallets. Rule engine 115 can reconfigure one or more rules to restrict access to the master account by one or more subordinate accounts and / or adjust wallet priorities for the use of available funds in one or more wallets. Rule engine 115 can communicate with data processing platform 117 in real-time or near real-time to transmit contextual data of one or more wallets associated with the state of the transaction carrier and / or business system.

[0079] In step 407, the issuing system 111 and the exchange system 113, via processor 602, can transmit a transaction request to a second subsystem (e.g., classification system 127) based on the presence of enhanced data and / or the status of the merchant system, for classifying one or more items associated with the request into one or more categories. Classification engine 231 can determine the correct APL to apply based on access device 101 and classify one or more items associated with the transaction request into one or more categories. In one embodiment, the issuing system 111 can determine that the merchant system is a participating merchant system. The issuing system 111 can transmit the transaction request to a third subsystem (e.g., exchange system 113), and the exchange system 113 can determine that the transaction data includes enhanced data. The exchange system 113 can then transmit the transaction request with the enhanced data to the classification system.

[0080] In one implementation, the classification engine 231 of classification system 127 can identify category and subcategory values ​​associated with one or more items identified in a transaction request by examining APLs in a database. In one implementation, classification system 127 manages the contents of an approved product list in the database. For example, a participating merchant system can add filtered items to or remove filtered items from the product list of an APL database inventory system. The initiator of access device 101 can add, remove, or reclassify APLs. In one implementation, the enhanced data may include SKU data, and the SKU data includes a unique identifier for each item sold by the participating merchant system.

[0081] In another implementation, the exchange system 113, via processor 602, can determine that the transaction data does not include item-level details and route the transaction to the data processing platform 117. This may occur when the self-categorized merchant system 203 has already provided self-categorized data or the non-participating merchant system 205 has already provided a standard authorization message without enhanced data. If the data processing platform 117 determines that it has not received category data and requests enhanced data from the merchant system 105, it can consult the rules engine 115 to determine if there are configured alternatives for the missing enhanced data for the merchant system. In one implementation, the self-categorized data includes data categorized by the self-categorized merchant system 203, corresponding to one or more items provided by the self-categorized merchant system 203. In one implementation, the data processing platform 117 uses data from the rules engine 115 to identify a single category that can be applied to select a wallet for the transaction.

[0082] In step 409, the data processing platform 117 executes the transaction request via the processor 602 based on one or more categories of each process described herein.

[0083] One or more implementations disclosed herein involve and / or utilize machine learning models. For example, one or more components of rule engine 115 (e.g., machine learning module 125) utilize machine learning models for implementation and / or for training machine learning models. Figure 5 The training flowchart 500 is used to train a given machine learning model. Training data 512 includes one or more of the stage inputs 514 and known outcomes 518 associated with the machine learning model to be trained. Stage inputs 514 come from any applicable source, including text, visual representations, data, values, comparisons, and stage outputs, such as those from [unclear source]. Figure 4One or more outputs of one or more steps. Known results 518 are included in machine learning models generated based on supervised or semi-supervised training. Unsupervised machine learning models may not use known results 518 for training. Known results 518 include known or expected outputs for future inputs that are similar to or belong to the same category as stage inputs 514 that do not have corresponding known outputs.

[0084] Training data 512 and a training algorithm 520 are provided to training component 530, such as one or more modules implemented using a machine learning model and / or used to train the machine learning model. The training component applies the training data 512 to the training algorithm 520 to generate the machine learning model. According to one implementation, a comparison result 516 is provided to training component 530, which compares the previous output of the corresponding machine learning model to apply the previous result to retrain the machine learning model. The comparison result 516 is used by training component 530 to update the corresponding machine learning model. Training algorithm 520 utilizes machine learning networks and / or models, including but not limited to deep learning networks such as deep neural networks (DNN), convolutional neural networks (CNN), fully convolutional networks (FCN), and recurrent neural networks (RCN); probabilistic models such as Bayesian networks and graphical models; classifiers such as K-nearest neighbors; and / or discriminative models such as decision forests and maximum margin methods, models specifically discussed herein, etc.

[0085] The machine learning model used in this paper is trained and / or used by adjusting one or more weights and / or one or more layers. For example, during training, given weights are adjusted (e.g., increased, decreased, or removed) based on training or input data. Similarly, layers are updated, added, or removed based on training and / or input data. The resulting output is adjusted based on the adjusted weights and / or layers.

[0086] Generally speaking, any process or operation discussed in this disclosure is understood to be computer-implementable, such as Figure 4 The processes illustrated herein are executed by one or more processors of a computer system as described herein. A process or process step executed by one or more processors is also referred to as an operation. One or more processors are configured to execute such a process by accessing instructions (e.g., software or computer-readable code) that, when executed by one or more processors, cause one or more processors to execute the process. The instructions are stored in the memory of the computer system. The processor is a central processing unit (CPU), a graphics processing unit (GPU), or any suitable type of processing unit.

[0087] A computer system, such as a system or apparatus that implements the processes or operations in the examples above, includes one or more computing devices. One or more processors of the computer system are included in a single computing device or distributed across multiple computing devices. One or more processors of the computer system are connected to data storage devices. The memory of the computer system includes the corresponding memory of each of the multiple computing devices.

[0088] Figure 6 An implementation of a computer system performing the techniques presented herein is illustrated. Computer system 600 includes a set of instructions that are executed to cause computer system 600 to perform any one or more methods or computer-based functions disclosed herein. Computer system 600 operates as a stand-alone device, or is connected to other computer systems or peripheral devices, for example, using a network.

[0089] Unless otherwise expressly stated, as will be apparent from the following discussion, it should be understood that throughout this specification, discussions using terms such as “processing,” “computing,” “calculating,” “determining,” “analyzing,” etc., refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulate data expressed as physical quantities (such as electronic quantities) and / or convert such data, expressed as physical quantities (such as electronic quantities), into other data similarly expressed as physical quantities.

[0090] In a similar manner, the term "processor" refers to any device or part of a device that processes electronic data, for example, from registers and / or memory, to convert that electronic data into other electronic data, for example, stored in registers and / or memory. "Computer," "computing machine," "computing platform," "computing device," or "server" includes one or more processors.

[0091] In a networked deployment, computer system 600 operates as a server, or as a client user computer in a server-client user network environment, or as a peer-to-peer (or distributed) computer system in a peer-to-peer (or distributed) network environment. Computer system 600 may also be implemented as or incorporated into various devices, such as personal computers (PCs), tablet PCs, set-top boxes (STBs), personal digital assistants (PDAs), mobile devices, handheld computers, laptop computers, desktop computers, communication equipment, wireless telephones, landline telephones, control systems, cameras, scanners, fax machines, printers, pagers, personal trusted devices, network devices, network routers, switches, or bridges, or any other machine capable of executing a set of instructions (sequentially or otherwise) specifying actions to be taken by that machine. In certain implementations, computer system 600 is implemented using electronic devices that provide voice, video, or data communication. Furthermore, while computer system 600 is exemplified as a single system, the term "system" should also be understood as any collection of systems or subsystems comprising one or more sets of instructions, individually or jointly, to perform one or more computer functions.

[0092] like Figure 6 As illustrated, computer system 600 includes processor 602, such as a central processing unit (CPU), graphics processing unit (GPU), or both. Processor 602 is a component in various systems. For example, processor 602 is part of a standard personal computer or workstation. Processor 602 is one or more processors, digital signal processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), servers, networks, digital circuits, analog circuits, combinations thereof, or other devices now known or hereafter developed for analyzing and processing data. Processor 602 implements software programs, such as manually generated (i.e., programmed) code.

[0093] Computer system 600 includes memory 604 that communicates via bus 608. Memory 604 is main memory, static memory, or dynamic memory. Memory 604 includes, but is not limited to, computer-readable storage media, such as various types of volatile and non-volatile storage media, including but not limited to random access memory, read-only memory, programmable read-only memory, electrically programmable read-only memory, electrically erasable read-only memory, flash memory, magnetic tape or disk, optical media, etc. In one implementation, memory 604 includes a cache or random access memory for processor 602. In alternative implementations, memory 604 is separate from processor 602, such as processor cache memory, system memory, or other memory. Memory 604 is an external storage device or database for storing data. Examples include hard disk drives, optical discs (“CDs”), digital video discs (“DVDs”), memory cards, memory sticks, floppy disks, universal serial bus (“USB”) memory devices, or any other device operable to store data. Memory 604 is operable to store instructions executable by processor 602. The functions, actions, or tasks illustrated in the figures or described herein are executed by processor 602, which executes instructions stored in memory 604. These functions, actions, or tasks are independent of a specific type of instruction set, storage medium, processor, or processing strategy, and are executed by software, hardware, integrated circuits, firmware, microcode, etc., operating individually or in combination. Similarly, processing strategies include multiprocessing, multitasking, parallel processing, etc.

[0094] As shown, computer system 600 further includes display 610, such as liquid crystal display (LCD), organic light-emitting diode (OLED), flat panel display, solid-state display, cathode ray tube (CRT), projector, printer, or other known or later developed display device for outputting determined information. Display 610 serves as an interface for a user to view the functions of processor 602, or specifically as an interface with software stored in memory 604 or drive unit 606.

[0095] Alternatively or additionally, computer system 600 includes input / output device 612 configured to allow a user to interact with any component of computer system 600. Input / output device 612 is a numeric keypad, keyboard, cursor control device such as a mouse, joystick, touchscreen display, remote control, or any other device operable to interact with computer system 600.

[0096] Computer system 600 also includes a drive unit 606, which is implemented as a disk or optical drive. Drive unit 606 includes a computer-readable medium 622 in which one or more sets of instructions 624 (e.g., software) are embedded. Furthermore, the set of instructions 624 embodies one or more methods or logic as described herein. During execution by computer system 600, the instructions 624 reside wholly or partially within memory 604 and / or processor 602. Memory 604 and processor 602 also include computer-readable media as discussed above.

[0097] In some systems, computer-readable medium 622 includes a set of instructions 624, or receives and executes a set of instructions 624 in response to a propagated signal, causing a device connected to network 630 to transmit voice, video, audio, images, or any other data through network 630. Furthermore, the set of instructions 624 is transmitted or received on network 630 via communication port or interface 620 and / or using bus 608. Communication port or interface 620 is part of processor 602 or a separate component. Communication port or interface 620 is created in software or is a physical connection in hardware. Communication port or interface 620 is configured to connect to network 630, external media, display 610, or any other component or combination thereof in computer system 600. The connection to network 630 is a physical connection, such as a wired Ethernet connection, or established wirelessly as discussed below. Similarly, additional connections to other components of computer system 600 are either physical connections or established wirelessly. Network 630 may alternatively be directly connected to bus 608.

[0098] Although computer-readable medium 622 is shown as a single medium, the term "computer-readable medium" includes single or multiple media, such as centralized or distributed databases, and / or associated caches and servers storing one or more sets of instructions. The term "computer-readable medium" also includes any medium capable of storing, encoding, or carrying a set of instructions for execution by a processor or causing a computer system to perform any one or more methods or operations disclosed herein. Computer-readable medium 622 is non-transient and may be tangible.

[0099] Computer-readable medium 622 includes solid-state memory, such as a memory card or other package containing one or more non-volatile read-only memories. Computer-readable medium 622 is random access memory or other volatile rewritable memory. Additionally or alternatively, computer-readable medium 622 includes magneto-optical or optical media, such as disks or magnetic tapes or other storage devices, to capture carrier signals, such as signals transmitted via a transmission medium. Digital file attachments such as emails or other self-contained information archives or collections of archives are considered as distribution media as tangible storage media. Therefore, this disclosure is considered to include any and more of computer-readable media or distribution media in which data or instructions are stored, as well as other equivalents and successor media.

[0100] In alternative implementations, dedicated hardware implementations, such as application-specific integrated circuits (ASICs), programmable logic arrays (PLA), and other hardware devices, are configured to implement one or more methods described herein. Applications of devices and systems incorporating various implementations broadly encompass a wide range of electronic and computer systems. One or more implementations described herein utilize two or more specific interconnected hardware modules or devices to implement functionality, these modules or devices having associated control and data signals transmitted between and through modules, or being part of an ASIC. Therefore, the systems of this invention encompass software, firmware, and hardware implementations.

[0101] Computer system 600 is connected to network 630. Network 630 defines one or more networks, including wired or wireless networks. Wireless networks are cellular telephone networks, 802.10, 802.16, 802.20, or WiMAX networks. Furthermore, such networks include public networks such as the Internet, private networks such as intranets, or combinations thereof, and utilize various network protocols available now or developed later, including but not limited to TCP / IP-based network protocols. Network 630 includes wide area networks (WANs), such as the Internet, local area networks (LANs), campus networks, metropolitan area networks, direct connections such as via universal serial bus (USB) ports, or any other network that allows data communication. Network 630 is configured to couple one computing device to another to enable data communication between the devices. Network 630 is generally capable of using any form of machine-readable medium for transmitting information from one device to another. Network 630 includes communication methods for the propagation of information between computing devices. Network 630 is divided into subnets. Subnets allow access to all other components connected to them, or subnets restrict access between components. Network 630 is considered a public or private network connection and includes, for example, encryption or other security mechanisms used on the public Internet, such as virtual private networks.

[0102] According to various implementations of this disclosure, the methods described herein are implemented by software programs executable by a computer system. Furthermore, in exemplary non-limiting implementations, the implementation may include distributed processing, component / object distributed processing, and parallel processing. Alternatively, virtual computer system processing may be configured to implement one or more methods or functions as described herein.

[0103] Although this specification describes components and functions implemented in specific implementations with reference to particular standards and protocols, this disclosure is not limited to such standards and protocols. For example, standards used for transport on the Internet and other packet-switched networks (e.g., TCP / IP, UDP / IP, HTML, HTTP) represent examples of prior art. Such standards are periodically superseded by faster or more efficient equivalents with substantially the same functionality. Therefore, alternative standards and protocols with the same or similar functionality as those disclosed herein are considered their equivalents.

[0104] It should be understood that, in one embodiment, the steps of the method discussed are executed by a suitable processor (or multiple processors) of a processing (i.e., computer) system that executes instructions (computer-readable code) stored in a storage device. It should also be understood that this disclosure is not limited to any particular implementation or programming technique, and that this disclosure is implemented using any suitable technique for implementing the functions described herein. This disclosure is not limited to any particular programming language or operating system.

[0105] It should be recognized that in the above description of exemplary embodiments of the invention, various features of the invention are sometimes combined in a single embodiment, drawing, or description thereof for the purpose of simplifying the disclosure and aiding in understanding one or more aspects of the various inventive aspects. However, this approach of the disclosure should not be construed as reflecting an intention that the claimed invention requires more features than expressly recited in each claim. Rather, as reflected in the appended claims, the innovative aspect lies in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are thus expressly incorporated into that detailed description, wherein each claim exists on its own as a separate embodiment of the invention.

[0106] Furthermore, while some embodiments described herein include some features included in other embodiments but not all features included in other embodiments, combinations of features from different embodiments are intended to be within the scope of the invention and form different embodiments, as understood by those skilled in the art. For example, in the appended claims, any claimed embodiment may be used in any combination.

[0107] Furthermore, some embodiments herein are described as methods or combinations of elements of methods that can be implemented by a processor of a computer system or by other means of performing such functions. Thus, a processor having the necessary instructions for performing the elements of such methods or methods forms a means for performing the elements of such methods or methods. Moreover, the elements of the apparatus embodiments described herein are examples of means for performing the functions performed by those elements to achieve the objectives of the present invention.

[0108] Numerous specific details are set forth in the description provided herein. However, it should be understood that embodiments of the invention can be practiced without these specific details. In other instances, well-known methods, structures, and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0109] Therefore, although preferred embodiments of the invention have been described, those skilled in the art will recognize that other and further modifications can be made without departing from the spirit of the invention, and it is intended that all such variations and modifications fall within the scope of the invention. For example, any formula given above is merely representative of programs that can be used. Functions can be added or removed from the block diagram, and operations can be interchanged between functional blocks. Within the scope of the invention, steps can be added or removed from the described methods.

[0110] The subject matter discussed above should be considered illustrative rather than restrictive, and the appended claims are intended to cover all such modifications, improvements, and other implementations that fall within the true spirit and scope of this disclosure. Therefore, to the fullest extent permitted by law, the scope of this disclosure will be determined by the broadest permissible interpretation of the appended claims and their equivalents, and should not be bound or limited by the foregoing detailed description. While various implementations of this disclosure have been described, it will be apparent to those skilled in the art that many more implementations and variations are possible within the scope of this disclosure. Therefore, this disclosure is not limited except as provided in the appended claims and their equivalents.

Claims

1. A system comprising: One or more processors; and At least one non-transient computer-readable medium storing instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including: Receive a request from the first subsystem, wherein the request includes multiple data associated with the access device; Determine that the first subsystem, the access device, or a combination thereof are authorized to access the service; Determine context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes the expiration date of the one or more wallets, one or more rules associated with the one or more wallets, or a combination thereof; The request is transmitted to a second subsystem, at least in part based on the context data, the state of the first subsystem, or a combination thereof, for classifying one or more items associated with the request into one or more categories; and The request is executed based on one or more of the categories.

2. The system of claim 1, wherein determining that the first subsystem and / or the access device has authorization to access the service further comprises: Configure a Restricted Authorized Network (RAN) list, wherein the RAN list includes at least one of the following: RAN Merchant Category Code (MCC), RAN Merchant Identifier (MID), or RAN Network Name; and The transaction MCC, transaction MID, or transaction merchant system associated with the request is compared with the RAN MCC, the RAN MID, or the RAN network name to determine a match.

3. The system according to claim 2, further comprising: After determining that the transaction MCC, the transaction MID, or the transaction merchant system has been approved by the RAN MCC, the RAN MID, or the RAN network name, respectively, the one or more wallets are authenticated.

4. The system according to claim 2, wherein the system further comprises: After determining unsuccessful matches, the transaction MCC, the transaction MID, or a combination thereof are normalized; as well as The first subsystem is authenticated using the normalized MCC, the normalized MID, or a combination thereof.

5. The system of claim 1, wherein determining the context data of the one or more wallets further comprises: Monitor the one or more wallets to detect amounts credited to the one or more wallets near or after the expiration date; as well as Override the expiration date of one or more wallets to set an alternative expiration date to access the credited amount, wherein the alternative expiration date is based on a predetermined duration.

6. The system of claim 1, wherein determining the context data of the one or more wallets further comprises: Identify one or more subordinate accounts linked to a master account associated with the one or more wallets; as well as Reconfigure the one or more rules to restrict access to the master account by the one or more subordinate accounts, adjust wallet priorities for the use of available funds in the one or more wallets, or a combination thereof.

7. The system of claim 1, wherein transmitting the request to the second subsystem further comprises: Determine whether the first subsystem is a participating system or a self-classifying system; The request is transmitted to a third subsystem, wherein the third subsystem determines that the plurality of data includes enhanced data; as well as The request with the enhanced data is transmitted from the third subsystem to the second subsystem.

8. The system according to claim 7, further comprising: The second subsystem identifies the category and subcategory values ​​associated with the one or more items identified in the request by checking the approved product list in the database.

9. The system of claim 8, wherein the second subsystem manages the contents of the approved product list in the database, and wherein the participating system or the self-classification system adds filtered items to the potential product list in the database or removes the filtered items from the potential product list in the database.

10. The system of claim 7, wherein the enhanced data includes inventory unit data, and wherein the inventory unit data includes a unique identifier for one or more items sold by the participating system.

11. The system of claim 1, wherein transmitting the request to the second subsystem further comprises: Determine whether the first subsystem is a self-classifying system or a non-participating system; The request is transmitted to an exchange system, wherein the exchange system determines the details of the multiple missing data items at the level of the data missing items. as well as A configured alternative for determining the item-level details for the self-classification system or the non-participating system.

12. A computer-implemented method, the computer-implemented method comprising: One or more processors receive a request from the first subsystem, wherein the request includes multiple data associated with the access device; The one or more processors determine that the first subsystem, the access device, or a combination thereof is authorized to access the service; The one or more processors determine context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes the expiration date of the one or more wallets, one or more rules associated with the one or more wallets, or a combination thereof; The request is transmitted to the second subsystem by the one or more processors, at least in part, based on the context data, the state of the first subsystem, or a combination thereof, for classifying one or more items associated with the request into one or more categories; as well as The request is executed by the one or more processors based on the one or more categories.

13. The computer-implemented method of claim 12, wherein determining that the first subsystem and / or the access device has authorization to access the service further comprises: The one or more processors configure a Restricted Licensed Network (RAN) list, wherein the RAN list includes at least one of the following: RAN Merchant Category Code (MCC), RAN Merchant Identifier (MID), or RAN Network Name; and The one or more processors compare the transaction MCC, transaction MID, or transaction merchant system associated with the request with the RAN MCC, the RAN MID, or the RAN network name to determine a match.

14. The computer-implemented method according to claim 13, further comprising: After determining that the transaction MCC, the transaction MID, or the transaction merchant system has been approved by the RAN MCC, the RAN MID, or the RAN network name, the one or more processors shall authenticate the one or more wallets.

15. The computer-implemented method according to claim 13, further comprising: After determining that an unsuccessful match has occurred, the one or more processors normalize the transaction MCC, the transaction MID, or a combination thereof. as well as The first subsystem is authenticated by the one or more processors using the normalized MCC, the normalized MID, or a combination thereof.

16. The computer-implemented method of claim 12, wherein determining the context data of the one or more wallets further comprises: The one or more processors monitor the one or more wallets to detect amounts credited to the one or more wallets near or after the expiration date; as well as The one or more processors override the expiration date of the one or more wallets to set an alternative expiration date to access the credited amount, wherein the alternative expiration date is based on a predetermined duration.

17. The computer-implemented method of claim 12, wherein determining the context data of the one or more wallets further comprises: The one or more processors determine one or more subordinate accounts linked to a master account associated with the one or more wallets; as well as The one or more processors may reconfigure the one or more rules to restrict access to the master account by the one or more subordinate accounts, adjust wallet priorities for the use of available funds in the one or more wallets, or a combination thereof.

18. The computer-implemented method of claim 12, wherein transmitting the request to the second subsystem further comprises: The first subsystem is determined by the one or more processors to be either a participating system or a self-classifying system; The request is transmitted by the one or more processors to a third subsystem, wherein the third subsystem determines that the plurality of data includes enhanced data; as well as The request with the enhanced data is transmitted from the third subsystem to the second subsystem via the one or more processors.

19. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to perform operations including: Receive a request from the first subsystem, wherein the request includes multiple data associated with the access device; Determine that the first subsystem, the access device, or a combination thereof are authorized to access the service; Determine context data of one or more wallets associated with the access device, the state of the first subsystem, or a combination thereof, wherein the context data includes the expiration date of the one or more wallets, one or more rules associated with the one or more wallets, or a combination thereof; The request is transmitted to a second subsystem, at least in part based on the context data, the state of the first subsystem, or a combination thereof, for classifying one or more items associated with the request into one or more categories; and The request is executed based on one or more of the categories.

20. The non-transient computer-readable medium of claim 19, wherein determining that the first subsystem and / or the access device has authorization to access the service further comprises: Configure a list of restricted authorized networks (RANs), wherein the RAN list includes at least one of the following: RAN Merchant Category Code (MCC), RAN Merchant Identifier (MID), or RAN network name; The transaction MCC, transaction MID, or transaction merchant system associated with the request is compared with the RAN MCC, the RAN MID, or the RAN network name to determine a match; as well as After determining that the transaction MCC, the transaction MID, or the transaction merchant system has been approved by the RAN MCC, the RAN MID, or the RAN network name, respectively, the one or more wallets are authenticated.

Images