Dynamic and predictive adjustment of payment attributes based on contextual data and metadata.

Abstract

[0003] Embodiments described herein relate to dynamic and predictive updating of payment attributes of a payment instrument. In some embodiments, a method includes receiving, at a computing device, route data for a plurality of trips; receiving, at the computing device, first trip data for a first trip from a user device, the first trip data including at least location data of the user device; calculating a fuel likelihood score for the first trip based on the received first trip data; comparing the fuel likelihood score to a first threshold; based on a determination that the fuel likelihood score satisfies the first threshold, sending a message to a computer associated with a payment network to update one or more payment attributes stored in the payment network and associated with the first payment instrument; and displaying an indication that the first payment instrument is authorized for fuel transactions.

Description

Technical Field

[0001] Cross-Reference to Related Applications This application claims the benefit of U.S. Patent Application No. 17 / 488,136, entitled "DYNAMIC AND PREDICTIVE ADJUSTMENT OF PAYMENT ATTRIBUTES BASED ON CONTEXTUAL DATA AND METADATA", filed on September 28, 2021, which claims priority to U.S. Provisional Patent Application No. 63 / 084,565, entitled "MACHINE LEARNING & RISK BASED AUTOMATON FOR FLEET,FUEL,FUNDING,& CAR CONTROLS", filed on September 29, 2020, U.S. Provisional Patent Application No. 63 / 152,353, entitled "FLEET CARD AUTHORIZATION UNDER CONDITIONS OF LIMITED CONNECTIVITY", filed on February 23, 2021, and Greek Patent Application No. 20210100451, entitled "HIGH AVAILABILITY REAL-TIME AUTHORIZATION OF TRANSACTIONS", filed on July 1, 2021. All of the foregoing applications are incorporated herein by reference in their entirety for all purposes.

[0002] Embodiments generally relate to predictive adjustment of payment attributes based on contextual data, and specifically to dynamic and predictive adjustment of payment attributes for fuel-related transactions.

Background Art

[0003] Payment instruments are commonly used by companies to cover expenses incurred by their employees. For example, in a typical fleet operation, a driver is provided with a credit card to pay for fuel and other incidental expenses incurred during operation.

[0004] However, employees may misuse payment methods to use them for personal expenses. Such misuse can be difficult to detect using conventional technologies and techniques. [Overview of the project] [Means for solving the problem]

[0005] One or more computer systems can be configured to perform specific operations or actions by having software, firmware, hardware, or a combination thereof installed on the system that causes the system to perform an operation while it is running. One or more computer programs can be configured to perform specific operations or actions by including instructions that cause a data processing device to perform an operation when executed by that device. One common embodiment includes a method for updating the payment attributes of payment instruments associated with vehicles in a fleet that includes multiple vehicles.This method involves a computing device receiving route data for multiple operations, wherein the route data for each of the multiple operations includes a corresponding geofence area, a corresponding user identifier, a corresponding payment method identifier, and a corresponding vehicle identifier for each operation; receiving transmission of one or more data packets from a user device, which may include a user identifier and a vehicle identifier; authenticating the vehicle identifier and user identifier using the computing device; identifying a first operation among the multiple operations based on matching the user identifier and vehicle identifier with the route data, wherein the first operation is associated with a first payment method; and the computing device The method includes receiving first operational data for a first operation from a user device, wherein the first operational data includes at least location data of the user device; calculating a fuel likelihood score for the first operation based on the received first operational data, wherein the fuel likelihood score indicates the reasonableness of the fuel transaction; comparing the fuel likelihood score to a first threshold; sending a message to a computer associated with the payment network to update one or more payment attributes stored in the payment network and associated with the first payment method, based on the determination that the fuel likelihood score satisfies the first threshold; and displaying or triggering a display on an application running on the user device indicating that the first payment method is approved for the fuel transaction. The method also includes displaying or triggering a display on an application running on the user device for a request for additional verification data, based on the determination that the fuel likelihood score does not satisfy the first threshold but satisfies a second threshold. This method also includes receiving additional verification data from the user's device, calculating an updated fuel likelihood score for the first run based on the additional verification data and the received first run data, and comparing the updated fuel likelihood score with a first threshold.The method also includes, based on the determination that the updated fuel likelihood score satisfies a first threshold, sending a message to a computer associated with the payment network to update one or more payment attributes stored in the payment network and associated with a first payment instrument, and displaying or triggering an indication on an application running on a user device that the first payment instrument is approved for a fuel transaction. Other embodiments of this aspect include a corresponding computer system, device, and a computer program recorded on one or more computer storage devices, each configured to perform the operations of the method.

[0006] Embodiments may include one or more of the following features: The method includes receiving authorization requests from a payment network for a fuel transaction in two or more groups of authorization control pods, wherein the authorization request includes an identifier associated with a first payment method and transaction information relating to the transaction, each authorization control pod includes a processing service, a database service, and a policy agent, and the corresponding policy agent of a single authorization control pod in the group of authorization control pods may include analyzing the transaction information by comparing one or more transaction attributes in the transaction information combined with context and historical data with one or more policies stored in the database service, and, based on the comparison, sending one of the approval or rejection of the transaction to the payment network. Calculating a fuel likelihood score for a first operation includes providing first operation data to a trained machine learning model. The fuel likelihood score is calculated based on the first operation data and received telemetry data, and the computing device stores the first operation data and received telemetry data in a linked data structure. Receiving the first operational data may include receiving a number of packets transmitted from a software application in a first cycle based on one or more of the time elapsed since the scheduled start of operation and the distance elapsed since the start of operation. Embodiments of the described technology may include hardware, methods or processes, or computer software on a computer-accessible medium.

[0007] One general embodiment includes a method for updating payment attributes of a payment instrument. This method includes: receiving instructions for an operation undertaken by a vehicle using a computing device which may include a processor and memory; associating a user device, a user identifier, and a vehicle identifier with the operation using the computing device; receiving operation data, including at least location data obtained from the user device, from an application running on the user device of the vehicle's user using the computer device; calculating a fuel likelihood score for the operation based on the received operation data, wherein the fuel likelihood score indicates the reasonableness of the fuel transaction; comparing the fuel likelihood score to a first threshold; and, based on the determination that the fuel likelihood score satisfies the first threshold, sending a message to a computer associated with the payment network to update one or more payment attributes stored in the device of the payment network, wherein one or more payment attributes are associated with a payment instrument; and displaying an instruction on the application running on the user device that the payment instrument is authorized for the fuel transaction. Other embodiments of this embodiment include corresponding computer systems, devices, and computer programs recorded on one or more computer storage devices, each configured to perform the operations of this method.

[0008] Embodiments may include one or more of the following features: The method may include, based on the determination that the fuel likelihood score does not satisfy a first threshold but satisfies a second threshold, displaying or triggering a request for additional verification data on an application running on a user device; receiving additional verification data from the user device; calculating an updated fuel likelihood score for the operation based on the additional verification data and the received operation data; comparing the updated fuel likelihood score with the first threshold; and, based on the determination that the fuel likelihood score satisfies the first threshold, sending a message to a computer associated with the payment network to update one or more payment attributes stored in the payment network's equipment, wherein one or more payment attributes are associated with a payment instrument; and displaying or triggering an instruction on an application running on the user device that the payment instrument is authorized for a fuel transaction. Displaying or triggering a request for additional verification data may include displaying or triggering a request for one or more images of the vehicle's odometer, dashboard, or license plate, and receiving additional verification data may include receiving image data and corresponding image metadata. Calculating the fuel likelihood score may involve analyzing received image data and received image metadata to determine one or more of the odometer mileage and estimated fuel level. Analyzing received image data and received image metadata may also involve determining the distance traveled since the previous refueling event. Telemetry data may include two or more of the following: location data, fuel level data, and fuel consumption data. Calculating the fuel likelihood score may also involve applying a trained machine learning (ML) model to the operational data.An authorization request includes an identifier associated with a payment method and transaction information relating to the transaction. Each authorization control pod includes a processing service, a database service, and a policy agent. The corresponding policy agent of a single authorization control pod within a group of authorization control pods analyzes the transaction information by comparing one or more transaction attributes in the transaction information, combined with context and historical data, with one or more policies stored in the database service, and, based on the comparison, sends either an authorization or denial of the transaction to the payment network. Transaction attributes in the transaction information received from the payment network include a replenishment pump location identifier, and the analysis of the transaction information may include comparing the replenishment pump location identifier with location data received from the user device. Receiving operation data may include receiving multiple packets sent from the application in a first cycle based on one or more of the time elapsed since the scheduled start of operation and the distance elapsed since the start of operation. Embodiments of the technology described may include hardware, methods or processes, or computer software on a computer-accessible medium.

[0009] One general embodiment includes a persistent computer-readable medium which may contain instructions, the instructions including a computing device which may include a processor and memory which receive instructions for an operation undertaken by a vehicle, the computing device which associates a user device, a user identifier and a vehicle identifier with the operation, the computer device which receives operation data from an application running on the user device of the vehicle's user, including at least location data obtained from the user device, the computer device which calculates a fuel likelihood score for a first operation based on the received operation data which indicates the reasonableness of a fuel transaction, compares the fuel likelihood score to a first threshold, and, based on the determination that the fuel likelihood score satisfies the first threshold, sends a message to a computer associated with a payment network to update one or more payment attributes stored in the device of the payment network which indicate that one or more payment attributes are associated with a payment instrument, and displays on the application running on the user device an indication that the payment instrument is authorized for a fuel transaction. Another embodiment of this embodiment includes a corresponding computer system, device and a computer program recorded on one or more computer storage devices which are each configured to perform the operations of the Method.

[0010] Embodiments may include one or more of the following features: a persistent computer-readable medium, the operation may further include displaying or triggering a display of a request for additional verification data on an application running on a user device, based on a determination that the fuel likelihood score does not satisfy a first threshold but satisfies a second threshold; receiving additional verification data from the user device; calculating an updated fuel likelihood score for the operation based on the additional verification data and the received operation data; comparing the updated fuel likelihood score to the first threshold; and sending a message to a computer associated with a payment network to update one or more payment attributes stored in the device of the payment network, based on a determination that the fuel likelihood score satisfies the first threshold, the one or more payment attributes being associated with a payment instrument; and displaying or triggering a display on an application running on a user device indicating that the payment instrument is authorized for a fuel transaction. Displaying or triggering a request for additional verification data may include displaying or triggering a request for one or more images of the vehicle's odometer, dashboard, or license plate, and receiving additional verification data may include receiving image data and corresponding image metadata. An operation may further include, in two or more groups of authorization control pods, receiving authorization requests from the payment network for a fuel transaction, the authorization request including an identifier associated with the payment method and transaction information relating to the transaction, each authorization control pod including a processing service, a database service, and a policy agent, and in the corresponding policy agent of a single authorization control pod among the group of authorization control pods, analyzing the transaction information by comparing one or more transaction attributes in the transaction information combined with contextual and historical data with one or more policies stored in the database service, and, based on the comparison, sending one of the approval or rejection of the transaction to the payment network.Embodiments of the described technology may include hardware, methods or processes, or computer software on a computer-accessible medium. [Brief explanation of the drawing]

[0011] [Figure 1] This is a schematic diagram of an example system environment for dynamic and predictive adjustment of payment attributes based on contextual data and metadata, according to several embodiments. [Figure 2] Examples of payment method management systems according to several embodiments are shown. [Figure 3A] The following are example screenshots of the user interface of a user device used with a payment management system, according to several embodiments. [Figure 3B] The following are example screenshots of the user interface of a user device used with a payment management system, according to several embodiments. [Figure 4A] This flowchart shows examples of methods for dynamic and predictive adjustment of payment attributes based on contextual data and metadata, according to several embodiments. [Figure 4B] This flowchart shows an example of a method for updating the payment attributes of a payment instrument, according to several embodiments. [Figure 5] This flowchart shows another example of a method for updating the payment attributes of a payment instrument, according to several embodiments. [Figure 6] According to several embodiments, example graphs illustrating fuel likelihood scores as a function of time and events are shown. [Figure 7] This is a block diagram showing examples of fuel likelihood score calculations according to several embodiments. [Figure 8] This is a schematic diagram of an example system architecture for providing high-availability real-time authorization for transactions, according to several embodiments. [Figure 9A]This is an example of a method for high-availability real-time authorization of transactions in an authorization control pod, according to several embodiments. [Figure 9B] This is an example of a method for high-availability, real-time authorization of transactions in a payment network (card processor) according to several embodiments. [Figure 10A] Examples of state and policy update transmission according to several embodiments are shown. [Figure 10B] This is a schematic diagram showing examples of region models according to several embodiments. [Figure 11] This document presents example workflows for policy evaluation, following several embodiments. [Figure 12] This document presents examples of policy evaluation by a policy engine, following several embodiments. [Figure 13] This is a block diagram showing examples of computing devices according to several embodiments. [Modes for carrying out the invention]

[0012] The following detailed description includes references to the accompanying drawings, which form part of it. In the drawings, unless otherwise indicated, similar symbols typically identify similar components. The exemplary embodiments described in the detailed description, drawings, and claims are not intended to limit. Other embodiments may be available, and other modifications may be made without departing from the spirit or scope of the subject matter presented herein. The aspects of this disclosure can be arranged, substituted, combined, separated, and designed in a wide variety of different configurations, as broadly described herein and illustrated in the drawings, all of which are contemplated herein.

[0013] References to "some embodiments", "one embodiment", "example embodiments", etc. within the specification indicate that although the described embodiments may include a specific feature, structure, or characteristic, not all embodiments necessarily include the specific feature, structure, or characteristic. Similarly, references to "some embodiments", "one embodiment", "example embodiments", etc. within the specification indicate that although the described embodiments may include a specific feature, structure, or characteristic, not all embodiments necessarily include the specific feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment or embodiment. Furthermore, when a specific feature, structure, or characteristic is described in connection with an embodiment, such feature, structure, or characteristic may be implemented in connection with other embodiments regardless of whether it is explicitly described or not.

[0014] Companies generally provide payment methods for their employees to use for purchases. Payment methods may include credit cards, digital wallets, tokens, and the like. Credit card fraud and misuse occur frequently and can lead to unnecessary expenditures.

[0015] Monitoring the use of payment methods such as credit cards presents challenges, particularly when expenditures occur remotely. For example, companies that maintain a fleet of vehicles, such as service providers offering services like plumbing, electrical work, moving companies, trucking operators, etc., typically incur expenditures that are borne away from the business hub. For example, refueling costs, meal expenses while traveling, etc., may be difficult to monitor.

[0016] The technology of the present disclosure can be applied to a payment method such that a user's specific context can be monitored and expenditure can be dynamically approved (permitted) based on the detected user context. In some embodiments, payment methods may be configured such that they are disabled by default at a retailer or other location, and are only enabled based on signals or messages transmitted to a payment network that adjust one or more payment-related attributes. The present technology can be applied to open payment network systems with minimal changes to elements within payment infrastructure, such as card processing workflows, retailer processing workflows, and the like. This can provide advantages compared to closed payment network systems, where a payment method is only valid for use at selected retailer facilities.

[0017] Adjustment of payment attributes can be utilized to implement smart expenditure management, for example, by only enabling transactions within categories pre-approved by an employer. For example, dynamic adjustment of payment attributes can be utilized to allow transactions only within a specific merchant category code (MCC) or only for selected merchants. In addition, expenditure limits may also be imposed for different categories of transactions.

[0018] In some embodiments, an authorization (auth) threshold may be specified, which may be updated continuously such that it is pre-calculated before an actual authorization request reaches the balance inquiry workflow. This may allow the workflow to be successfully executed within an allocated time budget, while the allocated time budget may not be sufficient for real-time (or substantially real-time) calculation of the authorization threshold.

[0019] Adjusting payment attributes can be used within various payment systems. For example, some payment systems may be configured such that when a request for authorization of a transaction is received from a retailer in the payment network, such as a card processor, the request and details of the proposed transaction are sent to a computer associated with the issuer of the payment instrument (or a designated manager acting on behalf of the issuer) regarding the approval or rejection of the transaction.

[0020] In some other payment systems, policies and rules may be provided to the payment network, for example, by the issuer, and each received transaction is evaluated based on those policies and / or rules to approve or reject the transaction. For the benefit of efficient transaction processing, outer (or upper) limits are usually specified, and in some embodiments, the time available (or made available) to approve or reject a transaction is typically limited to, for example, 5 seconds, 7 seconds, etc.

[0021] The technology described herein enables dynamic monitoring of user context based on received data, thereby enabling pre-processing of data related to transaction approval and / or rejection. Dynamic and predictive adjustment of payment attributes ensures that calculation, rule evaluation, policy evaluation, and / or decision parts of the workflow are performed well before the transaction request itself. Such a design of the payment processing workflow ensures that it can be addressed with a limited time budget for granting authorization.

[0022] User context can be used to further dynamically adjust payment attributes based on the detected user context. The context state is determined based on data automatically received from one or more user devices, such as mobile phones, tablets, onboard computers, vehicle-mounted transponders, computer systems, etc.

[0023] In some embodiments, a software application (app) may be installed on the user's device to enable the determination of the user context. The app may be configured to be always on or to be launched only during periods when the user intends to conduct financial transactions. The software application may be given appropriate user permissions to enable context monitoring, collection of data elements from one or more sensors, transmission of data elements and metadata elements to a payment means management system, etc.

[0024] The data may include data elements, such as image data and location data, and metadata elements, such as image capture time, image capture location, and authentication method, associated with one or more received data elements.

[0025] In some embodiments, predictive techniques, such as Kalman filtering and Wiener filtering, may be used to determine the future state of one or more parameters being tracked based on the current and previous states of those parameters.

[0026] In some embodiments, current and previous states may be provided to a machine learning model (ML) to determine the predicted state of one or more parameters. For example, in a fleet payment management solution, a clustering algorithm may be applied to a tuple of data including location data, timestamp data, driver data, fuel event data, vehicle data, vehicle load data, etc., to determine the likelihood of a fuel event for a particular vehicle in operation.

[0027] ML models can be trained on historical data. This historical data can be organizational (e.g., other employees within the organization), industry-specific (e.g., across companies within the same industry), and / or across organizations / industries (e.g., aggregated data). The system may also take into account preferences, patterns, or settings configurable by each user and / or company. Input data for the clustering algorithm may include historical data from a driver's previous runs, data from runs undertaken by other vehicles in the fleet, and aggregated data from other fleets.

[0028] In some embodiments, a transaction likelihood score can be calculated that may indicate the reasonableness of a future transaction. A high score for a future transaction may indicate a high reasonableness and therefore a low likelihood of fraud or abuse, while a low transaction likelihood score may indicate a low reasonableness and therefore a higher probability of the transaction being fraudulent or abused.

[0029] In some embodiments, one or more payment attributes may be updated and / or adjusted, for example, in a computing device associated with a payment network, based on a calculated transaction likelihood score. In some embodiments, a policy or rule may be adjusted or updated based on a calculated transaction likelihood score.

[0030] For example, a payment method may be configured to be disabled for use with any Retailer Category Code (MCC), and therefore may be configured in an inactive state. Based on the calculated transaction likelihood score, one or more MCCs may be turned on (e.g., approved for a transaction), and one or more transaction limits may be adjusted.

[0031] Transaction approval may have very limited time budgets, which can present computational challenges in accurately determining the user context state. The techniques described herein can be used to accurately predict the context state, mitigating abuse and fraud while still satisfying the given computational and time budgets. High-availability architectures for transaction processing and the provision of authorization for transactions are also described.

[0032] The techniques described herein also enhance transaction security by detecting the likelihood of fraud even before fraudulent activity is attempted, which offers significant advantages over detecting fraud after the transaction.

[0033] Figure 1 is a schematic diagram of an example system environment for dynamic and predictive adjustment of payment attributes based on contextual data and metadata, according to several embodiments.

[0034] As shown in Figure 1, this system environment includes a payment means management system 110, which is connected to a fleet management system 120 and one or more payment networks 140 via a network 160.

[0035] User devices 130a-130n and retailer computer systems 150a-150n are also connected to the network and configured to send and receive signals and / or messages from one or more of the fleet management system 120, payment network 140, and payment means management system 110.

[0036] User devices 130a–130n can be any computer system or device used by a person or entity intending to provide transaction information to a retailer computer system, fleet management system, or payment means management system. Thus, user device 130 may be represented by a laptop or desktop computer 130a, a user mobile device 130n, or one or more other types of user devices (e.g., onboard computers, wearable devices, tablet computers, etc.). There may be more or fewer user devices than those shown in Figure 1, as represented by the ellipse. A user can be any person (e.g., an employee) or organization that inputs or otherwise provides transaction / transaction data, authentication data, location data, etc. User devices 130a–130n can communicate with the network 160 to transmit (send) or receive data or other communications to and from any of the connected systems and / or computing devices.

[0037] Retailer computer systems 150a–150n are associated with vendors and retailers that provide services / goods to users (e.g., fuel stations, charging stations, repair stations, car wash stations, airlines, restaurants, hotels, car rental companies, transportation services, etc.). Retailer computer systems 150a–150n may be associated with specific computer systems or devices, such as point-of-service (POS) terminals that process transactions with retailers.

[0038] The fleet management system 120 may be any combination of computer systems used to manage the operation of the fleet, for example, by providing route and dispatch data to the payment management system 110 via the network 160.

[0039] The payment network 140 may be a combination of one or more payment networks associated with computer systems that process transactions and payments. Communication between the payment network system 140 and the payment means management system 110 may be implemented via the network 160 and by direct connection.

[0040] Network 160 can be any distributed processing network used to transmit information between two or more computer systems. Network 160 may include any type of known communication medium or set of communication mediums and may use any type of protocol to carry messages between devices. In some embodiments, Network 160 may also represent a telephone system or other means of transmitting information from user equipment to the payment means management system 110 and / or other components, from the retailer computer system 150 to the payment means management system 110 and / or other components, from the payment network 140 to the payment means management system 110 and / or other components. Thus, Network 160 can represent a system or network for completing transactions, or other types of communication systems. Network 160 can be an intranet, the internet, the World Wide Web, etc. In other embodiments, Network 160 may be a public switched telephone network (PSTN) or other types of telephone systems.

[0041] Network 160 may also include a WAN or LAN in some embodiments. Alternatively or additionally, Network 160 may include one or more devices not managed by the same entity that manages the payment means management system 110. The Internet is an example of Network 160, which constitutes an IP network consisting of many computers, computing networks, and other communication devices located around the world, connected through many telephone systems and other means. Other examples of Network 160 include, without limitation, standard conventional telephone systems (POTS), Integrated Digital Networks (ISDN), Public Switched Telephone Networks (PSTN), mobile communication networks, and any other type of packet-switched or circuit-switched network known in the art.

[0042] Figure 2 shows examples of payment method management systems according to several embodiments.

[0043] An example embodiment of the payment instrument management system is described in conjunction with Figure 2, which represents any system or set of systems on which the various applications, services, scenarios, and processes disclosed herein can be implemented. The payment instrument management system 110 may be employed to provide payment instrument management services on behalf of financial institutions, or to run a fleet management system on behalf of a company, such as those described herein.

[0044] The payment method management system 110 may include several processor-readable software modules that perform the functions described herein when executed by a processor. The modules may also be implemented on one or more distributed computing systems, and instances, processes, and / or functions may be available to perform the functions described herein.

[0045] The payment method management system 110 includes an authentication module 204 that securely authenticates users, vehicles, vendors, companies, etc., using one or more single-factor or multi-factor authentication marks. An example mark includes something the subject knows, something the subject possesses, and what the subject is.

[0046] The payment instrument management system 110 includes a pre-validation module 206 that determines the likelihood of future transactions based on contextual data. The pre-validation module may include a machine learning module that learns from previous transactions to generate and reinforce contextual data, rules, and / or learning to continuously improve the accuracy of the payment instrument management system. The pre-validation system may also include a context module to which deterministic rule sets and heuristic rule sets can be applied. The payment instrument management system 110 includes a rule module 214 and a policy module 216 that are used to resolve rules.

[0047] The payment means management system 110 includes a communication module 210 that enables inter-device communication between the payment means management system 110 and devices associated with a payment network, fleet management systems, financial institutions, retailers, companies, and any connected databases. The various modules communicate via signaling media such as buses, local networks, wide area networks, and similar.

[0048] The communication module 210, when executed by the processor, may enable the payment means management system 110 to communicate with other devices within the system 100. For example, the communication module 210 may be configured to modulate / demodulate information exchanged through the network 160, determine the timing associated with such information, determine the address associated with such information, and so on. In some embodiments, the communication module 210 may be configured to assign a communication port of the transaction monitor 101 for use as a communication interface. The communication module 210 may be further configured to generate messages according to the communication protocol used by the network 160 and to parse messages received through the network 160.

[0049] The payment method management 110 includes a transaction module 208 for processing transactions and a settlement module 212 for processing transaction settlement data. The abuse and fraud detection module 218 is included to detect fraudulent and abusive activity using the payment method based on detected data patterns.

[0050] The payment instrument management system 110 includes a financial institution module 220 for interacting with financial institutions that issue physical or digital financial instruments used to complete transactions.

[0051] The payment network module 222 may be used to interact with the payment network, process incoming messages, and send messages used to make one or more adjustments and / or updates to payment attributes stored on devices associated with the payment network. The payment means management system 110 includes a context module 224 for determining context data (including a context feedback loop) for a transaction.

[0052] The payment method management system 110 includes an approval module 226 that approves or rejects transactions received by the payment method management system.

[0053] The payment method management system 110 may include one or more databases, for example, a history database 230 and a policy and rules database 240.

[0054] Figures 3A and 3B show example screenshots of the user interface of a user device used with a payment method management system according to several embodiments.

[0055] In some embodiments, user devices, such as a user's (driver's) mobile device, are used to obtain contextual data and to provide the user with notifications(s). This illustrated example illustrates techniques applied in a fleet management context.

[0056] The software application for the payment (means) management system is configured to run on the user's device. The software application may be made available to the user for download. In some embodiments, the installation and execution of the software application may be specified as a requirement for the user to access one or more payment means.

[0057] The first screenshot (310) shows an example of a user verification screen. In some embodiments, the user may provide their authentication information, such as a username, password, or PIN, to sign in to the software application. Multiple authentication modes may be available, including facial recognition and fingerprint recognition.

[0058] The second screenshot (320) shows an example of a vehicle verification screen. In some embodiments, the user may be prompted to authenticate the vehicle being used for operation. Vehicle authentication may be supported by a transponder scanning an image of the license plate, an image of the VIN number plate, an image of the odometer, or other markings such as a QR code that may be placed inside the vehicle, in which case the QR code is unique to that vehicle.

[0059] A third screenshot (330) shows an example of additional verification that may be used in several scenarios. Images of the vehicle's odometer or the area around the vehicle may be requested via the user device. The user interface allows the user to be guided to take a photograph by providing guidance frames and by providing instructions to the user to move the user device appropriately to obtain an image that satisfies certain specifications.

[0060] The technology of this disclosure allows a fuel likelihood score to be calculated based on received operational data, and if the fuel likelihood score satisfies a predetermined threshold, the payment means associated with the user equipment (and user) can be pre-validated for the fuel transaction.

[0061] The fourth screenshot (340) shows an example screenshot illustrating successful pre-verification. Successful pre-verification may also be shown on a map on the user's device, indicating the approved fuel locations along the user's proposed route.

[0062] Additional indicators (not shown) may also be used. For example, a green indicator (e.g., a green dot) on the user interface of a software application may function as an indicator that the payment method is approved for refueling, a yellow indicator that additional verification data is required before successful pre-verification of the payment method, and a red indicator that pre-verification is unlikely.

[0063] The fifth screenshot (350) shows an example of a screenshot where discounted prices may be displayed to the user via their user device. Based on received operational data, advice and suggestions may be provided to the user via the user interface. Advice and / or suggestions may originate from the payment means management system, payment management system, or fleet management system and be displayed on the user device. The sixth screenshot (360) shows an example of a notification that may be provided. For example, if it is determined that a vehicle is located near the only fuel station within a certain distance from its current location, and based on operational data, the fuel level is estimated to be low, a notification recommending refueling may be provided.

[0064] Figure 4A is a flowchart illustrating examples of methods for dynamic and predictive adjustment of payment attributes based on contextual data and metadata, according to several embodiments.

[0065] In some embodiments, Method 400 can be implemented on a payment means management system 110, for example, as described with reference to Figure 1. In the examples described, the implementation system includes one or more digital processors or processing circuits ("processors") and one or more storage devices. In some embodiments, one or more different server and / or client components can execute different blocks or other parts of Method 400. In some examples, the first device is described as an execution of a block of Method 400. In some embodiments, one or more blocks of Method 400 can be executed by one or more other devices (e.g., other client devices, via a distributed computer system, or server devices) that can transmit results or data to the first device.

[0066] In some embodiments, Method 400, or a portion of the Method, can be automatically initiated by a system. In some embodiments, the implementation system is a first device. For example, the Method (or a portion thereof) can be executed periodically or based on the occurrence of one or more specific events or conditions, such as a detected change in the user context, a signal received from a card / payment processor, and / or one or more other states that can be specified in the settings read by the Method.

[0067] Processing may begin from block 410.

[0068] In block 410, one or more payment methods associated with a specific user, along with associated payment method data, may be received.

[0069] Payment method data may include data elements associated with the payment method, such as payment method identifiers, user identifiers, and budget limits related to the payment method.

[0070] The payment method can be any type of payment method, such as a physical card with a card number, a virtual card, a wallet, or a bank account.

[0071] Block 415 may follow Block 410.

[0072] In block 415, one or more computing devices are associated with a user. One or more computing devices may include user devices, such as a mobile phone associated with the user, a desktop, tablet, or laptop computer associated with the user; storage devices and, in particular, data structures associated with the user.

[0073] Block 420 may follow Block 415.

[0074] In block 420, context data and metadata associated with the context data may be received from the computing device.

[0075] Block 425 may follow Block 420.

[0076] In block 425, the likelihood score for future financial transactions is determined based on the received contextual data and metadata.

[0077] For example, context data may be received from one or more user devices and from one or more corporate computer systems. For instance, if an organization and / or a user grants permission for a payment management system to access calendar data from the user's calendar app and / or other apps installed on the user's device, the calendar data may be used as attribute and / or context data. Context data can also be determined from publicly available information that can be accessed, for example, through an application programming interface (API). For example, flight arrival and departure information, traffic data, weather data, etc., may be used as context data.

[0078] In some embodiments, user devices and data and metadata elements received from user devices(s) may be used for additional context. For example, if it is determined that a user is on the move and not at their desk, any transactions originating from (or claimed to originate from) their desktop computer are unlikely to be valid. Accordingly, the user's presumed movement status may be used to refine the user context.

[0079] Block 430 may follow Block 425.

[0080] In block 430, it is determined whether the likelihood score satisfies a predetermined threshold, such as a confidence threshold.

[0081] If the likelihood score is determined to satisfy a predetermined threshold, block 435 may follow block 430; otherwise, block 430 may follow block 420.

[0082] In block 435, one or more payment attributes or policies associated with a payment method(s) may be adjusted.

[0083] For example, an MCC code for a payment method may only be activated when it is determined that a future transaction using that payment method is valid and likely to occur. Depending on the payment architecture, for example, in a payment network that supports balance inquiries, pre-approved amounts or policies may be adjusted based on the transaction likelihood score. Similarly, a retailer or multiple retailers within a geofenced area may pre-validate or pre-approve a transaction based on user location data and a determination that the user is likely to conduct transactions within that geofenced area.

[0084] The techniques described herein can be used to provide faster transaction processing by reducing the time required to perform certain calculations and thereby reducing the computational load when actual transactions are initiated, for example, by a submitted permission request, such as a card swipe or wallet transaction.

[0085] Blocks 410-435 can be executed (or repeated) in a different order than described above, and / or one or more steps can be omitted.

[0086] Figure 4B is a flowchart showing examples of methods for updating the payment attributes of a payment instrument, according to several embodiments.

[0087] In some embodiments, Method 450 can be implemented on a payment means management system 110, for example, as described with reference to Figure 1. In the examples described, the implementation system includes one or more digital processors or processing circuits ("processors") and one or more storage devices. In some embodiments, one or more different server and / or client components can execute different blocks or other parts of Method 450. In some examples, the first device is described as executing a block of Method 450. In some embodiments, one or more blocks of Method 450 can be executed by one or more other devices (e.g., other client devices or server devices) that can transmit results or data to the first device.

[0088] In some embodiments, Method 450, or a portion of the Method, can be automatically initiated by a system. In some embodiments, the implementing system is a first device. For example, the Method (or a portion thereof) can be executed periodically or based on the occurrence of one or more specific events or conditions, such as the reception of new operational data, a signal received from a user device or payment network, and / or one or more other conditions that can be specified in the settings read by the Method.

[0089] Method 450 may begin with block 454.

[0090] In block 454, operational instructions and / or signals undertaken by the vehicle may be received by a computing device including a processor and memory.

[0091] In some embodiments, instructions may be determined based on signals received from the user device, such as sign-in, or based on the detection of a change in the user device's location. For example, estimation may be based on the reception of data from the user device from a first location and a second location at different times.

[0092] In some embodiments, instructions may be received from a fleet operator computer system. In some embodiments, instructions may be received from a software application (app) running on a user device in a computer device. In some embodiments, instructions may be transmitted based on user input at the start of operation. The user device may be associated with a vehicle driver or user, and the instructions may include additional data, such as a user device identifier, vehicle identifier, etc.

[0093] In some embodiments, the user and / or vehicle may be authenticated. For example, the user may be authenticated by requiring the user to enter an alphanumeric PIN, enter a multi-factor authentication key transmitted by a computer device to a known and trusted device associated with the user, or provide biometric data such as fingerprint and / or facial biometric data, using additional authentication means.

[0094] In some embodiments, a vehicle may be authenticated based on received images of its license plate, a QR code or other mark placed on the vehicle, a vehicle VIN number plate, and / or a vehicle odometer. The received images may be verified based on images previously acquired / received and stored in a database associated with a payment method management system.

[0095] In some embodiments, a mark attached to the vehicle may be used for authentication. For example, a QR code affixed inside the vehicle may be used. The user may be asked to scan the QR code using their user device, which may then be received by the payment management system based on a message transmitted by the user device.

[0096] In some embodiments, payment methods associated with operations and / or users may also be authenticated based on access to a database containing data stored regarding payment methods issued to employees, or based on user input of a payment method identifier, and / or combined with an alphanumeric identifier or token received from an image (of a physical card or other payment method) or an application running on the user's device. In some embodiments, previously provided (and authenticated) payment methods may be associated with a particular user based on historical data records.

[0097] In some embodiments, a payment instrument is configured to be in an inactive state, for example, not eligible for a transaction unless a message / signal adjusting one or more payment attributes of the payment instrument is sent to the payment network. For example, an MCC code for fuel purchases may be turned off as the initial state for a payment instrument. In some other embodiments, a payment instrument may be configured to be pre-approved (pre-validated) for selected transactions, for example, emergency supplies, repair services, and fuel transactions up to a specified amount limit, so that selected transactions are permitted even without adjustment of payment attributes.

[0098] In some embodiments, fuel-related data, such as the vehicle's initial fuel status and / or odometer readings, may also be acquired and stored as a reference for operation. Fuel-related data may be acquired based on image recognition of the odometer and / or fuel gauge from a computing device associated with the fleet management system, or based on data entered by the user via a user interface.

[0099] Block 454 may be followed by Block 456.

[0100] In block 456, the user device and vehicle (identifier) ​​are associated with operation by the computer device.

[0101] In some embodiments, user devices and vehicle identifiers are associated with operations based on received and authenticated data, while in other embodiments, previously received route data and / or historical data may also be used for association.

[0102] Following these associations, data received from the user device is used as a surrogate to the vehicle data, unless conflicting data is received.

[0103] Block 456 may be followed by Block 458.

[0104] In block 458, the computer device receives operational data, which includes at least location data acquired from the user device. In some embodiments, the operational data is received from a software application (app) running on the user device of the vehicle's user.

[0105] In some embodiments, the transmission of operational data may be configured to be received at predetermined intervals (time intervals). The interval may be dynamically adjusted based on the time and / or distance elapsed since the start of operation. An adjustable interval may help conserve battery life for user equipment by not requiring frequent data transmission and not maintaining a network connection during operation.

[0106] In some embodiments, operational data may be collected at a first frequency local to the user device and transmitted by the user device at a second (e.g., lower) frequency. Furthermore, the software application may be configured to activate sensors on the user device only when data is acquired. For example, a GPS sensor on the user device may be configured to activate only when location data is acquired from the user device, thereby extending the battery life of the user device.

[0107] In some embodiments, the operational data may be received as a series of (data) packets transmitted from the application in a first cycle based on the time elapsed from the scheduled start time of operation and / or the distance elapsed from the start of operation. In some embodiments, the cycle may be based on the battery state of the user device.

[0108] In some embodiments, operational data is received based on a specific cycle or on an event threshold, such as a certain distance traveled while driving. In some embodiments, operational data is received as a response to a ping sent from a payment management system.

[0109] In some embodiments, if a user device ping fails to elicit a response, a specified pre-authorization may be transmitted to the payment network based on an agreement or arrangement with the fleet manager / fleet management system configuration.

[0110] In some embodiments, the operational data may include one or more of the following: location data, accelerometer data, connection data such as a network operator identifier, speed / velocity data, and the battery status of the user device.

[0111] In some embodiments, the operational data may be a combination of automatically detected data and user-entered data. For example, a user may initiate a request to pre-verify a future transaction to be received in a payment management system, and the received request may include one or more of the requested budget or fuel amount, current fuel status, location information, average mileage during operation, intended refueling pump location, or other refueling pump details.

[0112] Operational data may include one or more images, metadata associated with one or more of those images, and metadata associated with user devices. For example, one or more images may include images of the vehicle's odometer and / or dashboard.

[0113] In some embodiments, a software application may be configured to collect and store operational data and then transmit it for reception by a payment management system. For example, while a user device does not have a network connection, the software application may be configured to operate in offline mode and monitor the user context to retrieve data and metadata elements for transmission to the payment management system when the user device connection is restored.

[0114] In some embodiments, in offline mode, a software application may display a message on the user device regarding locations along the route where network connectivity is available (based on previously received operational and / or historical data). For example, network connectivity at locations along the route may be provided by facility operators, such as fuel stations, and may be provided at locations where the user device can be used to provide additional data and metadata elements to enable pre-verification before transactions, such as Wi-Fi, Bluetooth, NFC, or other connections.

[0115] In some embodiments, the payment management system may, based on historical data, determine that the network operator associated with the user device (such as a mobile phone operator or a mobile phone operator's roaming partner) does not have network coverage at a particular location. Once network connectivity is restored, data already captured on the software application may be transmitted to the payment management system.

[0116] In some embodiments, while the user device has limited or no network connectivity, the refueling pump may provide the user (in offline mode) with instructions to proceed with the input of payment method data, such as card numbers, wallet data, or tokens. In such embodiments, transaction authorization may be provided by the payment network, for example, for a limited authorization amount. In some embodiments, it may be confirmed, for example, based on the user device history of the connected network or a check of the low battery status of the user device, that the connection to the network operator associated with the user device operator is truly limited or unavailable.

[0117] Block 460 may follow Block 458.

[0118] In block 460, a fuel likelihood score for a first run is calculated based on the received run data. The fuel likelihood score indicates the reasonableness of the fuel transaction. In some embodiments, the fuel likelihood score may be a confidence score associated with a valid future transaction based on the received run data, such as current mileage, metadata associated with one or more images, location, request time, etc.

[0119] The fuel likelihood score can be calculated using a variety of methods. In some embodiments, the fuel likelihood score is calculated in a computing device of a payment management system based on a determination of the distance traveled, the amount of fuel consumed, the amount of fuel remaining in the vehicle, and / or the expected amount of fuel. This determination may be based on received operational data, such as received location data, received odometer images(s), etc.

[0120] In some embodiments, calculating a fuel likelihood score may involve analyzing received image data and received image metadata to determine one or more of the odometer mileage, estimated fuel level, and / or distance traveled since the previous refueling event.

[0121] In some embodiments, received data and metadata elements can be validated. For example, the capture time and location of a received odometer image can be validated against the data transmission time and location, and the received odometer image can be validated to match a previously received odometer image by background matching. Similarly, pixel subtraction may be used with a previous odometer image to validate the odometer image, enabling faster extraction of mileage data from the odometer image.

[0122] In some embodiments, the received operational data may be supplemented by telemetry data from a transponder associated with the vehicle. The telemetry data may include one or more data elements, such as location data, fuel level data, speed data, and fuel consumption data.

[0123] In some embodiments, calculating the fuel likelihood score may involve applying a trained machine learning (ML) model to operational data.

[0124] Driver information, driver history, driver credit score, average mileage, last known location, connection history at location, authentication method (e.g., biometric authentication, facial recognition-based authentication, fingerprint-based authentication, PIN-based authentication, etc.), fuel status at the start of operation, elapsed time, vehicle type, and other characteristics are provided to the ML model, enabling the determination of a fuel likelihood score and the corresponding confidence interval for that score. Details of the additional fuel likelihood score(s) are explained with reference to Figure 7.

[0125] Block 460 may be followed by Block 462.

[0126] In block 462, it is determined whether the fuel likelihood score for the operation and / or vehicle satisfies the first threshold.

[0127] In some embodiments, the first threshold may be an indicator of the relatively high probability that the vehicle associated with the operation is in need of refueling.

[0128] If the fuel likelihood score is determined to satisfy the first threshold, block 464 may follow block 462; otherwise, block 468 may follow block 462.

[0129] In block 464, based on the determination that the fuel likelihood score satisfies a first threshold, a message may be sent to a computer associated with the payment network, for example, via an http or https channel, to update one or more payment attributes associated with the payment instrument. The payment attributes may be attributes, parameters, and / or configuration settings stored within the payment network's equipment.

[0130] For example, a message to unblock an MCC code for a fuel category may be sent to a computer associated with the payment network, based on a fuel likelihood score that satisfies a predetermined first threshold.

[0131] In some embodiments, payment attributes may be adjusted to the single refueling pump in the direction of travel that matches the route information transmitted to the payment means management system (based on extrapolation of current operation data).

[0132] Block 464 may be followed by Block 466.

[0133] In block 466, an instruction indicating that the payment method is approved for future fuel transactions is displayed on the application running on the user's device. For example, a list of approved fuel pumps (e.g., indicated by a checkmark or highlighted in a specific color) may be displayed on a map along with their current locations.

[0134] In some embodiments, the instruction may be a notification (e.g., a notification code) sent to the user device, which is displayed on the user interface of the user device by a software application running on the user device.

[0135] In some embodiments, the instructions may be text messages transmitted to the user's device, for example, via a mobile communication network. In some embodiments, the instructions may be displayed on an in-vehicle display.

[0136] Following the transmission of the message to the payment network, an authorization request may be received from the payment network for a transaction, such as a fuel transaction. For example, the request may be received in two or more groups of authorization control pods associated with a payment instrument management system and authorization requests from the payment network for a fuel transaction, and the authorization request includes an identifier associated with the payment instrument and transaction information about the transaction. Each authorization control pod may include processing services, database services, and policy agents.

[0137] The received request and transaction information may be analyzed by the corresponding policy agent of a single authorization control pod within a group of authorization control pods by comparing one or more transaction attributes within the transaction information, combined with contextual and historical data, with one or more policies stored in a database service. Based on this comparison, either an approval or rejection of the transaction may be sent (returned) to the payment network (e.g., a card processor).

[0138] In some embodiments, transaction attributes within transaction information received from a payment network may include a replenishment pump location identifier, and analysis of the transaction information may include comparing the replenishment pump location identifier with location data received from the user device. In some embodiments, a transaction may only be permitted if the replenishment pump location identifier matches the location data received from the user device.

[0139] In block 468, based on the previous determination that the fuel likelihood score does not satisfy a first threshold, it is determined whether the fuel likelihood score satisfies a second threshold. In some embodiments, the second threshold may be conveniently used in situations where additional operational data allows for improvement (updating) of the fuel likelihood score and calculation of a more accurate fuel likelihood score.

[0140] If the fuel likelihood score is determined to not satisfy the first threshold but to satisfy the second threshold, block 470 may follow block 468; otherwise, block 482 may follow block 468.

[0141] In block 470, a request for additional verification data is displayed or triggered on an application running on the user's device. The request may be displayed or triggered on the user's device and may include a request to capture and transmit one or more images of the vehicle's odometer, dashboard, or license plate.

[0142] In some embodiments, the request may include a request for an image of the vehicle's license plate and / or an image of the environment surrounding the vehicle, such as an image of the fuel pump, an image showing another vehicle, an image showing the front and rear of the vehicle, etc.

[0143] Block 470 may be followed by Block 472.

[0144] In block 472, additional verification data may be received from the user device, and this additional verification data may include, for example, image data and corresponding image metadata.

[0145] Block 474 may follow Block 472.

[0146] In block 474, an updated fuel likelihood score for an operation is calculated based on additional validation data and received operation data. The received additional validation data may be used to generate updated location and / or updated fuel status for the vehicle.

[0147] Block 474 may be followed by Block 476.

[0148] In block 476, the updated fuel likelihood score is compared to the first threshold.

[0149] If the updated fuel likelihood score is determined to satisfy the first threshold, block 478 may follow block 476; otherwise, block 458 may follow block 476.

[0150] In block 478, a signal / message is sent to a computer associated with the payment network to update one or more payment attributes stored within the payment network device, and one or more payment attributes are associated with a payment method.

[0151] Block 478 may be followed by Block 480.

[0152] Block 480 may display, or trigger, an instruction that the means of payment is approved for the fuel transaction. The instruction may be provided on an application running on the user's device.

[0153] In block 482, a second status indicator or notification may appear on the user's device indicating that the payment method has not been pre-verified for the transaction. In such a scenario, the user may be prompted to call their customer number. Block 458 may follow block 482.

[0154] A fuel likelihood score below a third threshold can be used as an indicator of more serious fraudulent activities, such as vehicle theft. For example, operational data received from user equipment and / or vehicle transponders may indicate a vehicle location outside a defined geofence. In such a scenario, an alert may be issued, or the vehicle may be locked by sending a message to the vehicle control system.

[0155] Blocks 454-482 can be executed (or repeated) in a different order than described above, and / or one or more steps can be omitted.

[0156] Figure 5 is a flowchart showing another example of a method for updating the payment attributes of a payment instrument, according to several embodiments.

[0157] In some embodiments, Method 500 can be implemented on, for example, a payment means management system 110 as described in relation to Figure 1. In the examples described, the implementation system includes one or more digital processors or processing circuits ("processors") and one or more storage devices. In some embodiments, one or more different server and / or client components can execute different blocks or other parts of Method 500. In some examples, the first device is described as executing a block of Method 500. In some embodiments, one or more blocks of Method 500 can be executed by one or more other devices (e.g., other client devices or server devices) that can transmit results or data to the first device.

[0158] In some embodiments, Method 500, or a portion of the Method, can be automatically initiated by a system. In some embodiments, the implementing system is a first device. For example, the Method (or a portion thereof) can be executed periodically or based on the occurrence of one or more specific events or conditions, such as an instruction to start operation, operation data received from a user device, a transaction request, a signal or message received from a payment network computer, and / or one or more other states that can be specified in the settings read by the Method.

[0159] Method 500 may begin with block 505.

[0160] In block 505, route data for multiple runs may be received by the computing device. For each run of the multiple runs, the route data may include a corresponding geofence area, a corresponding user (or driver) identifier, a corresponding payment method identifier, and a corresponding vehicle identifier.

[0161] In some embodiments, route data may include dispatch data including the planned route, the scheduled start time of the operation, the vehicle identifier of the vehicle to be used in the operation, and the user / driver for each operation of the route for a fleet including multiple vehicles.

[0162] In some embodiments, the corresponding geofence may be specified by a combination of the starting point, destination, one or more intermediate points, and one or more proposed paths of the journey.

[0163] In some embodiments, a corresponding geofence may be specified by designating a specific area of ​​movement, for example, a designated area which may include one or more locations and the area surrounding those locations. For example, in some embodiments, a geofence may be characterized by a polygon, circle, or irregular shape which includes one or more locations defined by longitude and latitude and defined by the boundaries of the geofence area.

[0164] Block 510 may follow Block 505.

[0165] In block 510, the transmission of one or more data packets may be received from a user device, such as a mobile phone, laptop computer, or in-vehicle computer. One or more data packets may be generated in a software application running on the user device, and one or more data packets may include a user identifier. In some embodiments, the authentication mode of the user device may also be obtained. In some embodiments, one or more data packets may include data elements and metadata elements associated with the corresponding data elements.

[0166] Block 510 may be followed by Block 515.

[0167] In block 515, the user identifier and vehicle identifier may be authenticated based on matching the received user and vehicle data with previously received authentication information and / or identifiers.

[0168] For example, a first vehicle may be identified based on a match between the received vehicle identifier and the received route data. Mobile device identifiers and / or user identifiers may also be associated with vehicle identifiers based on data input or images of license plates or VIN numbers, or from a previous association of a particular user (mobile) device with a vehicle.

[0169] The first operational data and any received telemetry data may be stored in a linked data structure for future authentication and for training machine learning (ML) models.

[0170] Block 520 may follow Block 515.

[0171] In block 520, a first operation among multiple operations may be identified based on the matching of an authenticated user identifier and an authenticated vehicle identifier with route data. In some embodiments, the first operation may also be associated with a first payment method.

[0172] Block 520 may be followed by Block 525.

[0173] In block 525, operational data is received from the authenticated user device.

[0174] The first operational data may be received as a series of packets transmitted from a software application in a first cycle based on one or more of the time elapsed from the scheduled start time of operation and / or the distance elapsed from the start of operation.

[0175] Block 530 may follow Block 525.

[0176] In block 530, a fuel likelihood score is calculated for the operation. The fuel likelihood score indicates the reasonableness of the fuel transaction. In some embodiments, the fuel likelihood score may be a confidence score associated with a valid future transaction based on received operation data, such as current mileage, metadata associated with one or more images, location, request time, etc.

[0177] The fuel likelihood score can be calculated using a variety of methods. In some embodiments, the fuel likelihood score is calculated in a computing device of a payment management system based on a determination of the distance traveled, the amount of fuel consumed, the amount of fuel remaining in the vehicle, and / or the expected amount of fuel. This determination may be based on received operational data, such as received location data, received odometer images(s), etc.

[0178] In some embodiments, calculating a fuel likelihood score may involve analyzing received image data and received image metadata to determine one or more of the odometer mileage, estimated fuel level, and / or distance traveled since the previous refueling event.

[0179] In some embodiments, received data elements and metadata elements can be validated. For example, the acquisition time and location of a received odometer image can be validated against the data transmission time and location, and the received odometer image can be validated to match a previously received odometer image by background matching. Similarly, pixel subtraction can be used with a previous odometer image to validate an odometer image.

[0180] In some embodiments, the received operational data may be supplemented by telemetry data from a transponder associated with the vehicle. The telemetry data may include one or more data elements, such as location data, fuel level data, and fuel consumption data.

[0181] In some embodiments, calculating the fuel likelihood score may involve applying a trained machine learning (ML) model to operational data.

[0182] Driver information, driver history, driver credit score, average mileage, last known location, connection history at location, authentication method (e.g., biometric, face-based, fingerprint-based, PIN-based), fuel status at start, elapsed time, vehicle type, and other features are provided to the ML model to enable the determination of a fuel likelihood score and the corresponding confidence interval for that score. Details of additional fuel likelihood scores are explained with reference to Figure 7.

[0183] Block 530 may be followed by Block 535.

[0184] In block 535, it is determined whether the fuel likelihood score for the operation and / or vehicle satisfies a first threshold. If it is determined that the fuel likelihood score for the operation and / or vehicle satisfies the first threshold, block 540 may follow block 535; otherwise, block 550 may follow block 535.

[0185] In block 540, based on the determination that the fuel likelihood score satisfies a first threshold, a message may be sent to a computer associated with the payment network, for example, via an http or https channel, to update one or more payment attributes associated with the payment instrument. The payment attributes may be attributes, parameters, and / or configuration settings stored within the payment network's equipment.

[0186] For example, a message may be sent from a processor to a computer associated with a payment network, and the message may include a request or command to unblock a retailer category code (MCC) for a fuel category based on a fuel likelihood score that satisfies a predetermined first threshold.

[0187] Block 540 may be followed by Block 545.

[0188] In block 545, an instruction indicating that the payment method is approved for future fuel transactions is displayed on the application running on the user's device. For example, a list of approved fuel pumps (e.g., indicated by a checkmark, highlighted in a specific color, etc.) may be displayed on a map along with their current locations.

[0189] In some embodiments, the instruction may be a notification (e.g., a notification code) sent to the user device, which is displayed on the user interface of the user device by a software application running on the user device.

[0190] In some embodiments, the instructions may be text messages transmitted to the user's device, for example, via a mobile communication network. In some embodiments, the instructions may be displayed on an in-vehicle display.

[0191] Following the transmission of the message to the payment network, an authorization request may be received from the payment network for a transaction, such as a fuel transaction. For example, the request may be received in two or more groups of authorization control pods associated with a payment instrument management system and authorization requests from the payment network for a fuel transaction, and the authorization request includes an identifier associated with the payment instrument and transaction information about the transaction. Each authorization control pod may include processing services, database services, and policy agents.

[0192] The received request and transaction information may be analyzed by the corresponding policy agent of a single authorization control pod within a group of authorization control pods by comparing one or more transaction attributes within the transaction information, combined with contextual and historical data, with one or more policies stored in a database service. Based on this comparison, either an approval or rejection of the transaction may be sent (returned) to the payment network (e.g., a card processor).

[0193] In some embodiments, transaction attributes within transaction information received from a payment network may include a replenishment pump location identifier, and analysis of the transaction information may include comparing the replenishment pump location identifier with location data received from a user device.

[0194] In block 550, based on the previous judgment that the fuel likelihood score does not satisfy the first threshold, it is determined whether the fuel likelihood score satisfies the second threshold.

[0195] If the fuel likelihood score is determined to not satisfy the first threshold but to satisfy the second threshold, block 555 may follow block 550; otherwise, block 585 may follow block 550.

[0196] In block 555, a request for additional verification data is displayed or triggered in an application running on the user's device.

[0197] A request may include a request to capture and transmit one or more images of the vehicle's odometer, dashboard, or license plate, which may be displayed on or triggered on the user's device.

[0198] In some embodiments, the request may include a request for an image of the vehicle's license plate and / or an image of the environment surrounding the vehicle, such as an image of a fuel pump, other vehicles, etc.

[0199] Block 555 may be followed by Block 560.

[0200] In block 560, additional verification data may be received from the user device, and this additional verification data may include, for example, image data and corresponding image metadata.

[0201] Block 560 may be followed by Block 565.

[0202] In block 565, an updated fuel likelihood score for an operation is calculated based on additional validation data and received operation data. The received additional validation data may be used to generate updated location and / or updated fuel status for the vehicle, and to generate an updated fuel likelihood score based on the updated location and / or fuel status.

[0203] Block 570 may follow Block 565.

[0204] In block 570, the updated fuel likelihood score is compared to the first threshold.

[0205] If the updated fuel likelihood score is determined to satisfy the first threshold, block 575 may follow block 570; otherwise, block 525 may follow block 570.

[0206] In block 575, a signal / message is sent to a computer associated with the payment network, for example, via an API or via an http / https channel, to update one or more payment attributes stored within the payment network device, and one or more payment attributes are associated with a payment method.

[0207] Block 580 may follow Block 575.

[0208] In block 580, a first status indicator, such as an indication that the means of payment is approved for the fuel transaction, may be displayed or triggered. The indication may be provided on an application running on the user's device.

[0209] Block 580 may be followed by Block 525.

[0210] In block 585, a second status indicator or notification may appear on the user's device indicating that the payment method has not been pre-verified for the transaction. The user may be prompted to contact the issuer or administrator associated with the payment method.

[0211] Blocks 505-585 can be executed (or repeated) in a different order than described above, and / or one or more steps can be omitted.

[0212] For example, in some embodiments, only a first threshold may be used, or only a second threshold may be used. For example, in some embodiments, all pre-verification may require the transmission of verification data (by the user device) for receipt in the payment means management system. In some embodiments, only automated pre-verification may be performed, for example, pre-verification may be performed based only on automatically detected and transmitted data, and data entered by the user may not be considered.

[0213] In some embodiments, block 580 may be executed before block 575.

[0214] Figure 6 shows example graphs illustrating fuel likelihood scores as a function of time and events, according to several embodiments.

[0215] In this example, the fuel likelihood score calculated for the operational example is shown on graph 600, which has time 605 on its X-axis and the fuel likelihood score 610 on its Y-axis. The graph also shows the first threshold (680) and the second threshold (690).

[0216] In some embodiments, the first threshold is a configurable parameter that indicates a fuel likelihood score level greater than the level at which a fuel trading event is judged to be a likely valid trade, for example, one that is relatively unlikely to be a fraudulent or abusive trade.

[0217] In some embodiments, the second threshold is a configurable parameter that indicates a fuel likelihood score level below which a fuel trading event is judged to be probably not a valid trade, below which there is a relatively high probability that it is, for example, a fraudulent or abusive trade.

[0218] The first and second thresholds may be determined based on historical fuel event data, vehicle type, vehicle load, the vehicle's corresponding fuel consumption (fuel efficiency), the type of terrain being driven on, etc. The thresholds may be set by the fleet operator and / or by the payment management system.

[0219] In this particular example, at the start of the operation (620)t1, the fuel likelihood score is calculated to be a relatively low number. This can be based on operational data including additional data indicating previous refueling events, and the time and distance the vehicle has traveled since the previous refueling event.

[0220] The fuel likelihood score is updated based on periodic recalculations (630) of the fuel likelihood score based on elapsed time and / or estimated distance traveled, and also based on data received from a user device (640), e.g., an authenticated user device associated with the vehicle. For example, in this illustrated example, the calculation of the fuel likelihood score at t2, t3, t4, and t6 is obtained based on periodic updates (e.g., at regular predetermined intervals), while the calculations at t6 and t7 are based on operational data received from the user device.

[0221] Periodic updates may be configured to have a specific periodicity, which may also change (decrease) as the elapsed time since the start of operation increases. The periodicity of updates may also be adjusted based on operational data received from user equipment.

[0222] For example, the fuel likelihood score may be calculated in a first calculation cycle during the initial part of the operation, and then in a second calculation cycle (less frequent than the first) towards the later part of the operation.

[0223] The fuel likelihood score can also be calculated based on updates received from user equipment that provide additional data on the distance traversed by the vehicle during operation.

[0224] In some embodiments, the fuel likelihood score may be recalculated each time an update is received from a user device associated with the operation. In some embodiments, a minimum time may be specified for the new calculation of the fuel likelihood score.

[0225] Figure 6 additionally shows a specific fuel likelihood score (655) greater than a first threshold, which the technology of the present disclosure points to, in order to automatically send a message to adjust payment attributes. In this illustrated example, the fuel likelihood score is updated (650) after it satisfies the first threshold.

[0226] In this example, Figure 6 shows the vehicle in operation (t 11 The fuel likelihood score (660) calculated after refueling is also shown, reflecting the fact that the vehicle is unlikely to need refueling again anytime soon. The next update of the fuel likelihood score (670) is also shown, calculated based on the update received from the user's device.

[0227] Figure 7 is a block diagram showing examples of fuel likelihood score calculations according to several embodiments.

[0228] Fuel likelihood scores can be calculated using a variety of techniques, such as deterministic techniques, machine learning (ML)-based techniques, predictive modeling techniques, and combinations of these techniques.

[0229] In this illustrated example, the received operation data 715a is used in the distance estimator 702 to determine the distance traveled since the previous fuel event. The estimated distance traveled may be determined based on operation data elements, such as location data, route information, odometer data, etc.

[0230] The vehicle's fuel consumption can be determined. The initial fuel state is obtained, for example, from the fleet management system, based on records of actual fuel events received or estimated based on historical operation and payment method data 708, or based on user input data or images.

[0231] The received image data may be processed by the image processor 704 to extract mileage and fuel status data by analyzing, for example, images from the odometer or fuel gauge. The fuel event predictor 706 may be used to predict future fuel events, for example, the predicted distance and time until the next fuel event. The predictor may use techniques such as Kalman filtering and Wiener filtering to predict possible fuel events (time and distance). A fuel likelihood score (A) 712 is calculated based on the fuel events predicted based on the operational data.

[0232] In some embodiments, the fuel likelihood score (A) may be used as a fuel likelihood score used for comparison with first and / or second thresholds, e.g., the first and second thresholds described with respect to Figure 4B, Figure 5, or Figure 6.

[0233] In some embodiments, the fuel likelihood score (A) may be combined with a fuel likelihood score (B) 740 calculated in a score generator 712 based on applying operational data to a machine learning model previously trained on actual route and refueling data from one or more fleets. A score generator 714 may be used to weight each fuel likelihood score stream to generate a fuel likelihood score 770 which can then be used for comparison with first and / or second thresholds.

[0234] Machine learning models can be implemented on a computer that includes memory with one or more processors and software instructions. In some embodiments, the one or more processors may include one or more general-purpose central processing units (CPUs), graphics processing units (GPUs), machine learning processors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or any other type of processor.

[0235] In this illustrated example, supervised learning is used to train a machine learning (ML) model 730 based on training data 710 and a feedback generator 750. The ML model 730 can be implemented using any suitable machine learning technique, such as a clustering algorithm, a log-likelihood algorithm, a feedforward neural network (FNN), or a convolutional neural network (CNN). In some embodiments, other machine learning techniques such as Bayesian models, support vector machines, and hidden Markov models (HMMs) can also be used to implement the ML model 730.

[0236] Training data 710 includes operation data 715b and corresponding payment method data 725 for one or more operations. Training data may be based on historical fuel records, for example, which include details such as the time(s) the vehicle was refueled, the location(s) where the vehicle was refueled, the price of the fuel, and the type of fuel. Training data may include data from one or more fleets.

[0237] In this illustrated example, operational data 715 is provided to a machine learning (ML) model 730 under training. The ML model generates a predicted fuel likelihood score 740 based on the current state of the ML model and data elements of the operational data, such as mileage, vehicle type, and driver data. For example, the ML model may determine a feature vector (or embedding) based on the features of the operational data 715. The feature vector (or embedding) may be a mathematical, multidimensional representation generated based on the operational data 715.

[0238] The ML model 730 can generate a predicted fuel likelihood score for an operation based on operational data, for example, based on feature vectors and / or similarity to feature vectors of other operational data associated with previous operations.

[0239] The predicted fuel likelihood score 740 generated by the ML model 730 is provided to the feedback generator 750.

[0240] The feedback generator 750 is also provided with ground truth payment means data 725 corresponding to the operation, as measured and / or reported. Feedback 760 is generated by the feedback generator 750 based on a comparison of the predicted likelihood score with the ground truth payment means data, such as where the vehicle was refueled, how far was covered, the duration between refueling events, etc. For example, if the predicted likelihood score 740 is within a predetermined threshold distance of the ground truth payment means data 725, positive feedback may be provided as feedback 760; on the other hand, if they are far apart and outside the threshold distance, negative feedback is provided to the ML model under training, which may be updated based on the feedback received using reinforcement learning techniques.

[0241] In some embodiments, the ML model includes one or more neural networks. A neural network may consist of multiple layers, each containing multiple layers. Each layer may contain multiple neural network nodes. Nodes within a particular layer may be connected to nodes in the preceding layer and the immediately following layer. In some embodiments, the ML model may be a convolutional neural network (CNN).

[0242] Training of an ML model can be performed periodically at specified intervals or triggered by an event. In some embodiments, training can be repeated until a threshold level of performance prediction accuracy is reached.

[0243] Figure 8 is a schematic diagram of an example system architecture for providing high-availability real-time authorization of transactions, according to several embodiments.

[0244] This service consists of two independent groups of permission control pods running within a distributed computing system, for example, a cluster located in different zones. Each pod within a group consists of the following containers:

[0245] • Processing container:

[0246] It performs signaling on the ISO-8583 channel.

[0247] Distribute incoming permission requests to employers (threads).

[0248] It receives policy and state updates from the application scope and stores them in the database container.

[0249] • Database container:

[0250] It holds policies associated with entities (cards, users, etc.).

[0251] It retains all the necessary state for evaluating the policy.

[0252] It performs synchronous replication in two directions to maintain the latest state across authorization control pods within the same zone. Real-time inter-zone database replication is not required, as outlined below.

[0253] • Policy Agent:

[0254] It receives the policy for evaluation.

[0255] It receives the status information necessary for evaluating the policy.

[0256] It returns a policy evaluation result of either approving or rejecting.

[0257] All pods within a zone are configured to connect to the same ISO-8583 IP address. Only one pod in a group can establish a valid link to the ISO-8583 channel (active pod), while the others remain in standby mode (standby pods). When the active pod terminates, one of the standby pods sets up a valid link to the ISO-8583 channel. Pods within a zone are distributed across different availability zones. According to this architecture, active pods are available within each zone.

[0258] ISO-8583 Signaling

[0259] The card processor (payment network) distributes each authorization request through all active ISO-8583 channels. Thus, both zones receive the same set of authorizations in the same order. Processing containers within each zone separately evaluate the policies to apply to incoming authorization requests and post their responses to the ISO-8583 channels. The card processor considers only the first response to arrive within the ISO-8583 channels and discards any further responses associated with a given authorization request.

[0260] High availability

[0261] An RDBMS is attached to each balance inquiry pod to enable low-latency access, allowing each pod to remain self-contained without relying on external services for approving incoming authorization requests. The RDBMS is set up in multi-master replication mode, which is necessary to avoid downtime during failover from the master to one of the slave instances. The RDBMS cluster is set up per region.

[0262] Each pod receives application entity lifecycle events (organization, user & card CRUD operations) through a message / event streaming service, such as a Kafka topic to which all pods are registered. Pods within each area are part of the same consumer group and therefore compete for the same messages. When a pod pulls a message from a Kafka topic, it updates its local RDBMS, and through replication, the changes are reflected in other pods within the same area. Thus, entity lifecycle events eventually reach all pods in all areas.

[0263] As mentioned in the ISO-8583 signaling section, each permission is delivered through both ISO-8583 channels. Permissions within each area are received by the main ISO-8583 channel read / write thread and processed as follows:

[0264] 1. The permission is committed to the local RDBMS with its status set to PENDING. This ensures that the associated amount is reserved before the next permission is processed.

[0265] 2. The authorization is assigned to the employer system for further processing.

[0266] 3. The employer system evaluates the policies related to permission.

[0267] 4. The employer system stores the evaluation results in the RDBMS and returns the results to the main ISO-8583 channel thread.

[0268] 5. The main thread writes the results to the ISO-8583 channel.

[0269] 6. The employer thread writes permission and evaluation results to a Pub / Sub topic. The Pub / Sub service is a multi-region, low-latency, reliable messaging service. Messages within this topic detect any permissions that may have been used and missed by pods in both regions and synchronize their locally maintained lists of permissions.

[0270] 7. The employer thread writes the permission and evaluation results to GCS object storage. This storage is used as backup storage for messages published to Pub / Sub, enabling the recovery of these messages in the event of a catastrophic failure in the area hosting the corresponding pod's Pub / Sub messages. It also serves as a last resort repository for processed permissions in the event of any other failures involving pods in both areas.

[0271] This layout can withstand both zone- and region-level failures without suffering message loss.

[0272] recovery

[0273] When a set of previously offline pods in a district are reactivated, it first catches up on the backlog of permissions missed through Pub / Sub messaging. Active pods in the recovering district must observe messages coming from both Pub / Sub and ISO-8583 channels until both are synchronized, ensuring that they do not begin evaluating new permissions from the ISO-8583 channel until all previous permissions have been received through Pub / Sub.

[0274] The recovering pod will perform the following:

[0275] 1. Pull messages from Pub / Sub topics and store them in the RDBMS.

[0276] 2. Pull messages from the ISO-8583 channel and store them in the RDBMS with a status of PENDING.

[0277] 3. If a message received from Pub / Sub already exists in the RDBMS in state PENDING (i.e., received via the ISO-8583 channel), the recovering pod is confident that it has received all messages and stored them in the RDBMS, and that the current balance is up-to-date. The pod can then resume normal operation, evaluating new messages from the ISO-8583 channel and providing responses.

[0278] Figure 9A shows an example of a method for high-availability real-time authorization of transactions in an authorization control pod, according to several embodiments.

[0279] In some embodiments, Method 900 can be implemented on, for example, a processing system 110 described in relation to Figure 1. In the examples described, the implementation system includes one or more digital processors or processing circuits ("processors") and one or more storage devices. In some embodiments, one or more different server and / or client components can execute different blocks or other parts of Method 900. In some examples, the first device is described as executing a block of Method 900. In some embodiments, one or more blocks of Method 900 can be executed by one or more other devices (e.g., other client devices or server devices) that can transmit results or data to the first device.

[0280] In some embodiments, Method 900, or a portion of the Method, can be automatically initiated by a system. In some embodiments, the implementation system is a first device. For example, the Method (or a portion thereof) can be executed periodically or based on the occurrence of one or more specific events or conditions, such as the receipt of a new transaction, a signal received from a card / payment processor, and / or one or more other states that can be specified in the settings read by the Method.

[0281] The process may begin at block 910.

[0282] At block 910, transaction information is received at one or more permission control pods. Block 910 may be followed by block 915.

[0283] At block 915, the received transaction information may be compared with one or more policies. Block 915 may be followed by block 920.

[0284] At block 920, it is determined whether the transaction information and context data satisfy one or more policies. If it is determined at block 920 that the transaction information and context data satisfy (e.g., comply with) one or more policies, block 920 may be followed by block 925; otherwise, block 920 may be followed by block 930.

[0285] At block 925, the transaction is approved.

[0286] At block 930, the transaction is rejected.

[0287] FIG. 9B is an example method of highly available real-time authorization for transactions in a payment network (card processor) in accordance with some embodiments.

[0288] In some embodiments, method 950, or portions thereof, may be automatically initiated by a system. In some embodiments, an implementation system is a first device. For example, the present method (or portions thereof) may be performed periodically, or performed based on the occurrence of one or more specific events or conditions, such as notification of a transaction from a retailer terminal, and / or one or more other conditions that can be specified in settings read by the method.

[0289] The process may begin at block 960.

[0290] In block 960, transaction information is received by the payment network (card processor) from the retailer terminal or the payment network. Block 965 may follow block 960.

[0291] Block 965 contains transaction information for two or more groups of authorized pods. Block 965 may be followed by Block 970. In Block 970, approval or rejection may be received from one or more groups of authorized pods. Block 975 may be followed by Block 975.

[0292] In block 975, it is determined whether the received approval or rejection is the first one received for the transaction. If the received approval or rejection is determined to be the first rejection, the approval or rejection is processed in block 980; otherwise, block 975 may be followed by block 960.

[0293] Figure 10A shows examples of state and policy update transmission according to several embodiments.

[0294] The application scope communicates updates to the authorization control pod via messaging. Updates include status updates (e.g., adding cards, budget updates, whitelisting / blacklisting MCCs, etc.) or policy updates (e.g., MCC-based approval policies, daily spending policies, etc.).

[0295] Both authorization control pods receive policy and state updates, apply them to their local databases, and upload the new policies to the policy agent.

[0296] An active authorization control pod sends all incoming authorizations to the application scope via messaging. In the case of authorization requests, the policy evaluation result is also sent.

[0297] In the case of permission denial, the message to the application scope will include the specific policy that resulted in the denial, in addition to the evaluation result.

[0298] Application Scope Data Model

[0299] policy

[0300] Application-scoped policies are parameterized, and the parameters are configurable by the customer. A set of policy templates is set up within the system. A policy template consists of a policy script template and a set of default values ​​for optional template parameters. A policy instance contains a set of policy template attributes and a reference to the basic policy template. A combination of a policy template and a policy instance (i.e., a set of instantiation parameters) can be used to generate the target policy script.

[0301] A policy instance is associated with a single entity: a single card, a single user, or a single organization / department. The associated entity UID, entity type (card, user, user group), and generated policy script are sent to the balance inquiry service via a message queue.

[0302] Reality update

[0303] The following operations are communicated to the balance inquiry service via the message queue:

[0304] • Any other card updates that affect card creation, deletion, and card operational status (blocked, lost / stolen, etc.): The creation operation triggers the creation of a card entity with externalId=card.uid in the balance inquiry service.

[0305] • User creation & deletion: A creation operation triggers creation of a user entity with externalId=user.uid in the balance inquiry service. In addition, a user group entity is created with externalId=user.org.uid in the balance inquiry service. A user deletion operation removes the user from the corresponding user group.

[0306] Balance inquiry data model

[0307] Policies

[0308] Policies can be attached to entities. An entity may be an individual card, an individual user, or a group of entities. Policies can be added, updated, or deleted. A policy is enabled by default and cannot be disabled unless it expires or is deleted. A policy may optionally have an effective date and / or an expiration date that indicate the period during which the policy is considered. Policies are self-contained, and their evaluation does not cause any side effects (e.g., state changes). Multiple policies can be attached to a user, a card, and a group. Multiple policies can be attached to one entity. Since policies are self-contained and do not cause side effects, multiple policies for a single entity can be evaluated in parallel.

[0309] FIG. 10B is a schematic diagram illustrating an example domain model in accordance with some embodiments.

[0310] A monitored state depends only on the input required by policy evaluation.

[0311] In the domain model example, individual cards, card users and groups, and users can be associated with one or more policies. Card grouping allows subsets of individual users to be associated with separate sets of policies. Similarly, organizations, departments, and divisions can all be modeled as groups of users. In addition, any incoming authorization requests are stored in the database of each service pod and used to evaluate policies requesting historical data (e.g., budget, per day, spend velocity).

[0312] Policy documents, along with policy scripts, optionally include effective and expire dates. Policy scripts are generated at the application scope and embed small amounts of data that do not change frequently (e.g., MCC scope).

[0313] The following table contains attribute names and descriptions for user groups, users, card groups, cards, and policies. [Table 1]

[0314] [Table 2]

[0315] [Table 3]

[0316] [Table 4]

[0317] [Table 5]

[0318] permission

[0319] The received authorization is immediately stored in the RDBMS with the status PENDING, and potential subsequent authorizations for the same account are processed in parallel, reflecting the available balance while the authorization is being evaluated.

[0320] expenditure

[0321] When the settlement report is processed and the authorization is matched with the settlement, a message is sent to the balance inquiry along with the expenditure object, which includes the final settlement amount and all associated authorization details. Authorizations associated with the expenditure are marked as matched and are not considered in the policy evaluation criteria. Instead, the corresponding settled expenditure object is considered when evaluating the policy.

[0322] Refunds are treated as expenses with a negative monetary value. Non-business expenses on business cards are flagged and placed in the expense object, and they are not considered during policy evaluation unless explicitly instructed otherwise by policy. Business expenses on personal cards are added to the balance inquiry as expense objects without associated permissions. These (manual) expenses may lack important attributes present in automated expenses (e.g., MCC details).

[0323] Account balance

[0324] Account balances are implemented as policies attached to user group entities. User groups include users who have cards backed by corresponding bank accounts. In unlikely scenarios where users have cards backed by different bank accounts, a corresponding card group must be maintained for each bank account, and policies are attached to these card groups.

[0325] Figure 11 shows example workflows for policy evaluation according to several embodiments.

[0326] Policy Evaluation

[0327] Policy evaluation is performed by combining the policy script with the input data. The data is provided in the following way: It can be embedded within a policy script. This is suitable for non-dynamic data with a relatively small size. • It can be provided as input during evaluation. This is suitable for dynamic data that needs to be explicitly provided each time a policy evaluation occurs. • It can be pulled by a policy script during evaluation. This is suitable for static or dynamic data of large size.

[0328] In addition, incoming permission requests are always provided as input to the policy. Permission requests are sanitized; that is, PCI scope data is removed or tokenized before the request is provided to the policy evaluation engine. Specifically, all occurrences of PAN are translated into their corresponding surrogate IDs.

[0329] The active pod receiving the permission request must perform the following steps:

[0330] 1. Retrieve all policies that apply directly or indirectly to incoming permission requests. These include:

[0331] 1. A policy directly associated with the card being queried within the authorization request.

[0332] 2. The policy associated with the group to which the card being queried belongs.

[0333] 3. The policy associated with the cardholder (user) of the card being queried.

[0334] 4. Policies associated with the group to which the cardholder belongs.

[0335] 2. Evaluate the retrieved policies that provide the incoming permission request as input to the policies. Policies can be evaluated sequentially or in parallel. The process terminates when one of the policies rejects the permission request.

[0336] 3. The pod transmits the evaluation results via the ISO-8583 link. The pod monitors steps 1-3. If the cumulative time for steps 1-3 exceeds a predetermined threshold, for example, 4.5 seconds, the process terminates and the pod returns a rejection message to the ISO-8583 link.

[0337] 4. The pod stores the permission request and evaluation results in the local RDBMS. The data is replicated to the failover pod.

[0338] 5. The pod sends the permission request and evaluation results to the app scope via a messaging / event logging service, such as Kafka.

[0339] The application-scoped submission evaluation results include the following attributes: [Table 6]

[0340] Figure 12 shows examples of policy evaluation by a policy engine according to several embodiments.

[0341] The policy script is uploaded to OPA via a call to the OPA's management REST API. The policy can then be evaluated via the data REST API.

[0342] In addition to the data embedded in the policy script, additional data is provided during policy evaluation from inputs and through HTTP calls from within the policy script. These HTTP calls are returned to the authorization controller, which provides a local (in-pod) REST API to the OPA container within the pod. The API includes calls related to dynamic data that is large in size or requires significant aggregation (non-trivial aggregation). For example, a policy enforcing a budget per MCC initiates calls to the authorization controller to retrieve an up-to-date map of per-MCC spending for a period specified within the policy.

[0343] The sample policy script is used to call a REST endpoint to retrieve current spending per MCC, which is then compared to the budget per MCC.

[0344] Figure 13 is a block diagram of an example computing device 1300 that may be used to implement any of the features described herein. In one example, device 1300 may be used to implement a computer device (e.g., 110, 120, 130, 140, and / or 150 in Figure 1) and perform suitable method embodiments described herein. Computing device 1300 can be any suitable computer system, server, or other electronic or hardware device. For example, computing device 1300 can be an instance in cloud computing or other distributed computing system, a mainframe computer, a desktop computer, a workstation, a portable computer, or an electronic device (such as a portable device, mobile device, cell phone, smartphone, tablet computer, television, TV set-top box, personal digital assistant (PDA), media player, game console, wearable device, etc.). In some embodiments, device 1300 includes a processor 1302, memory 1304, input / output (I / O) interface 1306, and audio / video input / output device 1314.

[0345] The processor 1302 can be one or more processors and / or processing circuits for executing program code to control the basic operation of the device 1300. “Processor” includes any suitable hardware and / or software system, mechanism, or component for processing data, signals, or other information. A processor may include a general-purpose central processing unit (CPU), a system with multiple processing units, dedicated circuits for achieving a function, or other systems. Processing does not need to be limited to a specific geographical location or may be subject to temporal constraints. For example, a processor may perform its functions in “real time,” “offline,” “batch mode,” etc. Parts of the processing may be performed at different times, at different locations, by different (or the same) processing systems. A computer can be any processor communicating with memory.

[0346] The computer-readable medium (memory) 1306 is typically provided within the device 1300 for access by the processor 1302, is suitable for storing instructions for execution by the processor, is located away from the processor 1302 and / or integrated within it, and may be any suitable processor-readable storage medium, such as random access memory (RAM), read-only memory (ROM), electrically erasable read-only memory (EEPROM), flash memory, etc. The memory 1304 can store software that runs on the server device 1300 by the processor 1302, including the operating system 1304, one or more applications 1310, and application data 1312. In some embodiments, the application 1310 may include instructions that enable the processor 1302 to perform (or control) some or all of the functions described herein, for example, some or all of the methods described in relation to Figures 4A, 4B, 5, 9A, or 9B.

[0347] The software elements in memory 1306 can, as an alternative, be stored in any other suitable storage location or on a computer-readable medium. In addition, memory 1306 (and / or other connected storage devices) can store instructions and data used in the features described herein. Memory 1306 and any other type of storage (magnetic disks, optical disks, magnetic tapes, or other tangible media) can be considered “storage” or “storage device.”

[0348] The I / O interface can provide functionality to enable the server device 1300 to interface with other systems and devices. For example, network communication devices, storage devices (e.g., memory and / or datastores), and input / output devices can communicate via the interface. In some embodiments, the I / O interface can be connected to an interface device that includes input devices (keyboards, pointing devices, touchscreens, microphones, cameras, scanners, etc.) and / or output devices (display devices, speaker devices, printers, motors, etc.).

[0349] Audio / video input / output devices may include user input devices (e.g., a mouse) that can be used to receive user input, display devices (e.g., a screen, monitor) that can be used to provide graphical and / or visual output, and / or combined input and display devices.

[0350] For simplicity of explanation, Figure 13 shows one block for each of the processor 1302 and memory 1306. These blocks may represent one or more processors or processing circuits, operating systems, memory, I / O interfaces, applications, and / or software engines. In other embodiments, the device 1300 may not have all of the illustrated components and / or may include other components, including other types of elements, instead of or in addition to those illustrated herein. While the processing system is described herein as performing operations as described in some embodiments, any suitable component or combination of components of the processing system, or any suitable processor or multiple processors associated with such system, may perform the operations described.

[0351] The user device may also implement and / or use with the features described herein. An example of a user device may be a computer device including components somewhat similar to device 1300, for example, a processor(s) 1302, memory 1306, etc. An operating system, software, and applications suitable for the client device may be provided in memory and used by the processor. The I / O interface for the client device may be connected to network communication devices, as well as input and output devices, such as a microphone for capturing sound, a camera for capturing images or video, a mouse for capturing user input, a gesture device for recognizing user gestures, a touchscreen for detecting user input, an audio speaker device for outputting sound, a display device for outputting images or video, or other output devices. A display device within an audio / video input / output device may be connected to (or included in) device 1300 to display, for example, image pre-processing and post-processing as described herein, and such a display device may include any suitable display device, such as an LCD, LED, or plasma display screen, a CRT, a television, a monitor, a touchscreen, a 3D display screen, a projector, or other visual display device. Some embodiments can provide audio output devices, such as speech output or text-to-speech synthesis.

[0352] One or more methods described herein (e.g., methods 400, 450, 500, 900, and / or 950) can be implemented by computer program instructions or code that can be executed on a computer. For example, code can be implemented by one or more digital processors (e.g., microprocessors or other processing circuits) and stored on a computer program product including a persistent computer-readable medium (e.g., a storage medium), such as a magnetic, optical, electromagnetic, or semiconductor storage medium, including semiconductor or solid-state memory, magnetic tape, removable computer diskette, random-access memory (RAM), read-only memory (ROM), flash memory, rigid magnetic disk, optical disk, solid-state memory drive, etc. Program instructions can also be included in electronic signals and provided as electronic signals, for example, in the form of software as a service (SaaS) delivered from a server (e.g., a distributed system and / or cloud computing system). Alternatively, one or more methods can be implemented in hardware (e.g., logic gates) or in a combination of hardware and software. Hardware examples can include programmable processors (e.g., field-programmable gate arrays (FPGAs), coupled programmable logic circuits), general-purpose processors, graphics processors, application-specific integrated circuits (ASICs), and similar. One or more methods can run as part or component of an application running on a system, or as an application or software running alongside other applications and the operating system.

[0353] One or more methods described herein can be performed as standalone programs that can run on any type of computing device, programs that run on a web browser, or mobile applications (apps) that run on mobile computing devices (e.g., mobile phones, smartphones, tablet computers, wearable devices (watches, armbands, jewelry, headwear, goggles, glasses, etc.), laptop computers, etc.). In one example, a client / server architecture can be used, for example, where a mobile computing device (as a client device) sends user input data to a server device and receives final output data from the server for output (e.g., display). In another example, all calculations can be performed within a mobile app (and / or other app) on a mobile computing device. In yet another example, calculations can be divided between a mobile computing device and one or more server devices.

[0354] The description is based on specific embodiments, but these specific embodiments are illustrative only. Concepts shown in the examples may apply to other examples and embodiments.

[0355] The functional blocks, operations, features, methods, apparatus, and systems described herein may be integrated into or separated into different combinations of systems, apparatus, and functional blocks, as will be apparent to those skilled in the art. Any suitable programming language and programming technique may be used to implement routines of a particular embodiment. Different programming techniques, e.g., procedural or object-oriented, may be employed. Routines may run on a single processing unit or on multiple processors. Steps, operations, or calculations may be presented in a specific order, but the order may be modified in different particular embodiments. In some embodiments, multiple steps or operations shown herein as sequential may be performed simultaneously. The term “automatic” and its variations herein refers herein to any process or operation that is typically sequential or semi-sequential, performed without significant human input when the process or operation is performed. However, even if the performance of a process or operation uses significant or unsignificant human input, if that input is received before the execution of the process or operation, the process or operation may be automatic. Human input is considered significant if such input affects how the process or operation is performed. Human input consenting to the execution of a process or operation is not considered "important."

[0356] The term “computer-readable medium” as used herein refers to any computer-readable storage and / or transmission medium involved in providing instructions to the processor for execution. Such computer-readable medium can be tangible, persistent, and non-temporary, and can take many forms, including but not limited to non-volatile, volatile, and transmission media, including, without limitation, random access memory ("RAM"), read-only memory ("ROM"), and similar. Non-volatile media include, for example, NVRAM, or magnetic or optical disks. Volatile media include dynamic memory, such as main memory. Common forms of computer-readable media include, for example, floppy disks (including, without limitation, Bernoulli cartridges, Zip drives, and JAZ drives), flexible disks, hard disks, magnetic tapes or cassettes, or any other magnetic media, magneto-optical recording media, digital video discs (such as CD-ROMs), any other optical media, punch cards, paper tapes, any other physical media with hole patterns, solid-state media such as RAM, PROM, and EPROM, flash EPROM, and memory cards, any other memory chips or cartridges, carriers as described below, or any other media that a computer can read. Digital file attachments to email or self-contained information archives or sets of archives are considered distribution media equivalent to tangible storage media. When computer-readable media is configured as a database, it is understood that the database can be any type of database, such as relational, hierarchical, object-oriented, and / or similar. Accordingly, this disclosure is considered to include tangible storage media or distribution media, as well as equivalents and successor media approved in the prior art, in which software embodiments of this disclosure are stored. Computer-readable storage media generally exclude temporary storage media, particularly those containing electrical, magnetic, electromagnetic, optical, and magneto-optical signals.

[0357] "Computer-readable storage medium" may, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or apparatus, or any suitable combination thereof. More specific examples (a non-exclusive list) of computer-readable storage medium include: electrical connections having one or more wires, portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In the context of this document, computer-readable storage medium may be any tangible medium that contains or can store programs for use by, or in connection with, an instruction execution system, device, or apparatus.

[0358] A “computer-readable signal medium” is not a computer-readable storage medium, but any computer-readable medium capable of transmitting, propagating, or transferring a program for use by, or in connection with, an instruction execution system, device, or apparatus. A computer-readable signal medium can transmit, for example, a propagating data signal containing computer-readable program code embodied therein, either within the baseband or as part of a carrier wave. Such a propagating signal can take any of various forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. Program code embodied on a computer-readable signal medium can be transmitted using any suitable medium, including, but not limited to, wireless, wired, fiber optic cables, RF, or any suitable combination thereof.

Claims

1. A method for updating the payment attributes of a payment method associated with a vehicle in a fleet including multiple vehicles, wherein the method is performed automatically by a computer commanded by computer software, and the method is In a computing device, the process involves receiving route data for multiple operations, wherein the route data for each of the multiple operations includes a corresponding geofence area, a corresponding user identifier, a corresponding payment method identifier, and a corresponding vehicle identifier for each operation. Receiving transmission of one or more data packets generated by a software application running on the user device from the user device, wherein the one or more data packets include a user identifier and a vehicle identifier. The computing device authenticates the vehicle identifier and the user identifier, Based on the matching of the user identifier and the vehicle identifier with the route data, a first operation among the plurality of operations is identified, wherein the first operation is associated with a first payment method. The computing device receives first operation data for the first operation from the user device, wherein the first operation data includes at least the location data of the user device. Based on the received first operational data, a fuel likelihood score is calculated for the first operational, wherein the fuel likelihood score indicates the reasonableness of the fuel transaction. The fuel likelihood score is compared with a first threshold, Based on the determination that the fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with the payment network to update one or more payment attributes stored in the payment network and associated with the first payment method, and Displaying or triggering an instruction on the application running on the user device that the first payment method is approved for the fuel transaction, Based on the determination that the fuel likelihood score does not satisfy the first threshold but does satisfy the second threshold: Display or trigger a request for additional verification data on the application running on the user device. Receiving the additional verification data from the user device, Based on the additional verification data and the received first operation data, calculate an updated fuel likelihood score for the first operation. The updated fuel likelihood score is compared with the first threshold, and Based on the determination that the updated fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with the payment network to update one or more payment attributes stored in the payment network and associated with the first payment method, and Displaying or triggering an instruction on the application running on the user device that the first payment method is approved for the fuel transaction, Methods that include...

2. In two or more groups of authorization control pods, receiving authorization requests from the payment network for fuel transactions, wherein the authorization requests include an identifier associated with the first payment method and transaction information relating to the fuel transaction, and each authorization control pod includes a processing service, a database service, and a policy agent. In the corresponding policy agent of a single authorization control pod among the group of authorization control pods, the transaction information is analyzed by comparing one or more transaction attributes in the transaction information, combined with context and historical data, with one or more policies stored in the database service. Based on the comparison, one of the approvals or rejections of the fuel transaction is transmitted to the payment network. The method according to claim 1, further comprising:

3. The method according to claim 1, wherein calculating a fuel likelihood score for the first operation includes providing the first operation data to a trained machine learning model.

4. Receiving telemetry data from a transponder attached to a vehicle associated with the vehicle identifier, wherein the fuel likelihood score is calculated based on the first operational data and the received telemetry data. In the computing device, the first operation data and the received telemetry data are stored in a linked data structure. The method according to claim 1, further comprising:

5. The method according to claim 1, wherein receiving the first operation data includes receiving a plurality of packets transmitted from the software application in a first cycle based on one or more of the time elapsed from the scheduled start time of the operation and the distance elapsed from the start of the operation.

6. A method for updating the payment attributes of a payment instrument, wherein the method is performed automatically by a computer instructed by computer software, and the method is A computing device including a processor and memory receives operational instructions undertaken by the vehicle, The computing device associates the user device, user identifier, and vehicle identifier with the operation. The computing device receives operational data, including at least location data, from an application running on the user device of the vehicle's user, Based on the received operational data, a fuel likelihood score is calculated for the said operation, wherein the fuel likelihood score indicates the reasonableness of the fuel transaction. The fuel likelihood score is compared with a first threshold, Based on the determination that the fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with a payment network to update one or more payment attributes stored in the payment network's device, wherein the one or more payment attributes are associated with a payment method, and Displaying an instruction on the application running on the user device that the payment method is approved for the fuel transaction, Methods that include...

7. Based on the determination that the fuel likelihood score does not satisfy the first threshold but does satisfy the second threshold: Displaying or triggering a request for additional verification data on the application running on the user device, Receiving the additional verification data from the user device, Based on the aforementioned additional verification data and the received operational data, an updated fuel likelihood score for the operation is calculated, The updated fuel likelihood score is compared with the first threshold, Based on the determination that the fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with a payment network to update one or more payment attributes stored in the payment network's device, wherein the one or more payment attributes are associated with the payment means, and Displaying or triggering an instruction on the application running on the user device that the payment method is approved for the fuel transaction, The method according to claim 6, further comprising:

8. The method according to claim 7, wherein displaying or triggering a request for additional verification data includes displaying or triggering a request for one or more images of the vehicle's odometer, dashboard, or license plate, and receiving the additional verification data includes receiving image data and corresponding image metadata.

9. The method according to claim 8, wherein calculating the fuel likelihood score includes analyzing received image data and received image metadata to determine one or more of the odometer mileage and the estimated fuel level.

10. The method according to claim 9, wherein analyzing the received image data and the received image metadata includes determining the distance traveled since a previous refueling event.

11. The method according to claim 6, further comprising receiving telemetry data from a transponder associated with the vehicle, wherein the telemetry data includes two or more of location data, fuel level data, and fuel consumption data.

12. The method according to claim 6, wherein calculating the fuel likelihood score includes applying a trained machine learning (ML) model to the operational data.

13. Applying the aforementioned trained ML model is The operation data is provided to the trained ML model to determine the first fuel likelihood score, The operational data is provided to the fuel event predictor to determine a second fuel likelihood score, The first fuel likelihood score and the second fuel likelihood score are combined to calculate a composite fuel likelihood score, The method according to claim 12, including the method described in claim 12.

14. In two or more groups of authorization control pods, receiving authorization requests from the payment network for the fuel transaction, wherein the authorization request includes an identifier associated with the payment method and transaction information relating to the fuel transaction, and each authorization control pod includes a processing service, a database service, and a policy agent. In the corresponding policy agent of a single authorization control pod among the group of authorization control pods, the transaction information is analyzed by comparing one or more transaction attributes in the transaction information, combined with context and historical data, with one or more policies stored in the database service. Based on the comparison, one of the approvals or rejections of the fuel transaction is transmitted to the payment network. The method according to claim 6, further comprising:

15. The method according to claim 14, wherein the transaction attributes in the transaction information received from the payment network include a replenishment pump location identifier, and the analysis of the transaction information includes comparing the replenishment pump location identifier with location data received from the user device.

16. The method according to claim 6, wherein receiving the operation data includes receiving a plurality of packets transmitted from the application in a first cycle based on one or more of the time elapsed from the scheduled start time of the operation and the distance elapsed from the start of the operation.

17. A non-volatile computer-readable storage medium containing instructions, wherein the instructions, in response to execution by a processing device, are transmitted to the processing device. A computing device including a processor and memory receives operational instructions undertaken by the vehicle, The computing device associates the user device, user identifier, and vehicle identifier with the operation. The computing device receives operational data, including at least location data, from an application running on the user device of the vehicle's user, Based on the received operational data, a fuel likelihood score is calculated for the said operation, wherein the fuel likelihood score indicates the reasonableness of the fuel transaction. The fuel likelihood score is compared with a first threshold, Based on the determination that the fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with a payment network to update one or more payment attributes stored in the payment network's device, wherein the one or more payment attributes are associated with a payment method, and Displaying an instruction on the application running on the user device that the payment method is approved for the fuel transaction, A non-volatile computer-readable storage medium that enables the execution of operations including [specific operations].

18. The aforementioned operation is, Based on the determination that the fuel likelihood score does not satisfy the first threshold but does satisfy the second threshold: Displaying or triggering a request for additional verification data on the application running on the user device, Receiving the additional verification data from the user device, Based on the aforementioned additional verification data and the received operational data, an updated fuel likelihood score for the operation is calculated, The updated fuel likelihood score is compared with the first threshold, Based on the determination that the fuel likelihood score satisfies the first threshold: Sending a message to a computer associated with a payment network to update one or more payment attributes stored in the payment network's device, wherein the one or more payment attributes are associated with the payment means, and Displaying or triggering an instruction on the application running on the user device that the payment method is approved for the fuel transaction, A non-volatile computer-readable storage medium according to claim 17, further comprising:

19. Displaying or triggering a request for additional verification data includes representing a request for one or more images of the vehicle's odometer, dashboard, or license plate, or triggering such display, and receiving such additional verification data includes receiving image data and corresponding image metadata, according to claim 18.

20. The aforementioned operation is, In two or more groups of authorization control pods, receiving authorization requests from the payment network for the fuel transaction, wherein the authorization request includes an identifier associated with the payment method and transaction information relating to the fuel transaction, and each authorization control pod includes a processing service, a database service, and a policy agent. In the corresponding policy agent of a single authorization control pod among the group of authorization control pods, the transaction information is analyzed by comparing one or more transaction attributes in the transaction information, combined with context and historical data, with one or more policies stored in the database service. Based on the comparison, one of the approvals or rejections of the fuel transaction is transmitted to the payment network. A non-volatile computer-readable storage medium according to claim 17, further comprising:

Images