Card Network Rulebooks and Agent-Initiated Transactions: Visa and Mastercard Compliance
How do Visa and Mastercard operating rules apply to agent-initiated card transactions? A compliance methodology for autonomous payment infrastructure.
The question of how card network rulebooks govern transactions where no human cardholder is present at the moment of execution has moved from a theoretical edge case to an operational priority across financial services, insurance, logistics, and subscription commerce. How do Visa and Mastercard operating rules apply to agent-initiated card transactions? The answer demands a systematic reading of both networks' core documentation, an understanding of how tokenization and credential-on-file frameworks interact with autonomous execution, and a clear methodology for building payment infrastructure that survives acquirer audits, chargeback disputes, and scheme-level compliance reviews.
The Regulatory Architecture Governing Non-Cardholder-Present Execution
Visa and Mastercard each publish operating regulations that run to thousands of pages, updated on a semi-annual cycle. Both documents share a foundational assumption: every transaction originates with an identifiable cardholder act. Agent-initiated transactions challenge that assumption structurally, because the entity executing the payment instruction is software, not a person holding a card.
Mastercard's rulebook addresses this through its distinction between cardholder-initiated transactions and merchant-initiated transactions, abbreviated as CIT and MIT respectively. Visa uses the same CIT/MIT taxonomy. Within the MIT category, both networks further divide authorization types by whether the cardholder provided a standing instruction, whether the merchant stored the credential, and whether the timing of subsequent charges was agreed upon in advance.
When an AI agent initiates a payment, the compliance question is not simply whether the network allows the transaction. The question is which MIT sub-category the transaction falls into, because each sub-category carries its own electronic commerce indicator, authorization reason code, and liability assignment. A misclassified agent-initiated charge is not merely a technical error; it is a scheme violation that can trigger acquirer fines or result in chargebacks that are unwinnable by design.
Both networks have updated their technical specifications in successive annual releases to accommodate recurring billing, installment plans, unscheduled credential-on-file charges, and industry-specific payment models. Agent-initiated transactions do not always fit cleanly into any one of those buckets, which is precisely why organizations deploying autonomous payment agents need a compliance methodology rather than a checklist.
CIT vs. MIT Classification as the First Decision Gate
Before any transaction reaches the network, the originating system must classify it. A cardholder-initiated transaction requires the cardholder to actively participate in authentication at the moment of payment. A merchant-initiated transaction uses a stored credential under a standing agreement the cardholder previously authorized.
Agent-initiated transactions almost always fall into the MIT category, but the classification only holds if the cardholder agreement underlying the credential storage meets both networks' requirements. Visa's stored credential framework requires that the initial transaction include explicit cardholder consent for future MIT charges, that the merchant store the credential in compliance with PCI DSS, and that each subsequent charge reference the original transaction identifier. Mastercard imposes materially identical requirements, and both networks verify compliance through the transaction data fields populated at the time of authorization.
The practical implication for agent systems is that the agent cannot simply retrieve a stored card number and submit it. The authorization request must carry the correct reason code, a reference to the original agreement transaction, and in many cases a stored credential indicator. If the agent is integrated at the API layer of a payment gateway, those fields may need to be explicitly mapped, because gateways do not always populate them automatically when the originating call comes from a non-human actor.
Misclassification risk is highest in scenarios where an agent is making a payment decision based on a business rule, such as automatically settling an invoice when a shipment is confirmed. That use case is legitimate under both networks' frameworks, but only if the original cardholder agreement expressly authorized charges triggered by fulfillment events, not merely recurring calendar-based billing.
Stored Credential Frameworks and What They Require at the Architecture Level
Both Visa and Mastercard require that the initial transaction establishing a stored credential be a CIT, meaning the cardholder must be present and authenticated when they first agree to future charges. This requirement has direct architectural implications for any system that will later execute agent-initiated payments.
The initial CIT must be authorized and approved, not merely attempted. Both networks prohibit using a declined transaction as the basis for a stored credential relationship. The authorization response for the approved CIT must be retained by the merchant or their payment processor, because the network transaction ID from that response is required as a reference in every subsequent MIT authorization.
Agent systems must be designed to store and retrieve this reference persistently, and the storage mechanism must survive system migrations, credential rotations, and database schema changes.
Visa additionally requires that if the stored credential will be used for unscheduled charges — meaning charges that do not occur on a fixed calendar cadence — the cardholder agreement must specifically authorize unscheduled charges rather than simply authorizing recurring ones. This distinction becomes consequential when an AI agent is executing payment instructions based on dynamic triggers, such as a balance threshold being reached or a service threshold being exceeded.
Mastercard introduced a similar requirement through its Transaction Processing Rules, noting that the cardholder disclosure must describe the nature of the charges with sufficient specificity to allow the cardholder to understand what they are agreeing to. For agent-initiated systems, this means the consent language captured at enrollment cannot simply be generic authorization to charge the card; it must describe the scenarios under which the agent will execute a payment.
Authorization Message Construction for Agent-Initiated Charges
The ISO 8583 message format underlies the vast majority of card authorization traffic globally, and both Visa and Mastercard define their own extensions and field requirements on top of the base standard. Agent-initiated transactions must populate specific fields correctly, or the transaction will either be declined or, worse, approved in a way that shifts liability in an unfavorable direction.
The electronic commerce indicator, or ECI, communicates authentication context to the issuer. For MIT charges where no real-time authentication is required, the appropriate ECI value differs from what would be used in a cardholder-present or 3D Secure authenticated transaction. Using the wrong ECI value is a compliance violation even if the transaction is approved, because issuers and networks audit ECI distributions and flag merchants whose patterns do not match their registered business model.
Both networks require that the authorization for an unscheduled MIT include a field indicating that the transaction is credential-on-file and that no cardholder is present. Visa's system uses the POS entry mode and the credential-on-file indicator in the authorization request. Mastercard uses a similar combination of fields including the MIT category code. Getting these right requires either a payment processor that explicitly supports MIT field mapping or a direct integration that gives the agent-side system enough control over the authorization message to populate them correctly.
A correctly constructed MIT authorization also references the prior network transaction identifier. Both Visa and Mastercard use this reference to link the current charge back to the original stored credential agreement, which is part of how issuers evaluate whether to approve or decline the transaction. Agents that submit MIT charges without this reference are not only out of compliance; they are also statistically more likely to receive declines because the issuer cannot validate the billing relationship.
Liability Allocation and the Chargeback Consequences of Non-Compliance
Liability allocation in card transactions depends heavily on authentication and authorization method. For agent-initiated charges, the liability framework is straightforward in principle but operationally complex: if the cardholder disputes a transaction as unauthorized, and the merchant cannot demonstrate that the charge was authorized under a valid stored credential agreement, the merchant loses the chargeback regardless of whether the underlying business claim is legitimate.
Both Visa and Mastercard have chargeback reason codes specifically for disputes involving recurring or credential-on-file charges. Visa's reason code 13.2 covers credit not processed, and reason code 13.3 covers not as described scenarios, but the most relevant for agent-initiated disputes is reason code 11.3, which covers no authorization. Mastercard uses a similar structure under its chargeback categories. Defending against a no-authorization dispute requires producing evidence that the initial CIT occurred, that the cardholder consented to future charges, and that the authorization message for the disputed transaction correctly identified it as an MIT.
The liability implications extend to the acquirer relationship as well. Acquirers set their own risk thresholds for MIT volumes, chargeback ratios, and authorization decline rates. An agent system that generates a high decline rate on MIT transactions — often because of missing reference fields or incorrect ECI values — will trigger acquirer scrutiny and potentially acquirer-imposed restrictions on MIT processing. Organizations running agent-initiated payment systems need to monitor their MIT authorization metrics the same way they monitor their CIT metrics.
Visa operates a program called the Global Merchant Chargeback Monitoring Program, and Mastercard operates the Excessive Chargeback Program. Both set thresholds that, when exceeded, result in monthly fines that scale with the volume of excess chargebacks. Agent-initiated transaction errors that generate chargebacks count toward these thresholds the same as any other chargeback, making technical compliance directly financial in impact.
The Agentic Payment Protocol Problem: When Agents Act Across Multiple Merchants
A single AI agent executing payments on behalf of a cardholder within a single merchant relationship is a relatively contained compliance problem. The more complex scenario arises when an agent operates across multiple merchant relationships, executing payments at different merchants using the same stored cardholder credential or delegating payment authority to sub-agents.
This multi-merchant, multi-agent scenario has no clean analogue in current Visa or Mastercard operating rules. The closest existing framework is the payment facilitator model, where a master merchant aggregates sub-merchants and takes responsibility for their compliance. But payment facilitators are human-operated organizations with defined registration requirements, sponsor bank relationships, and sub-merchant underwriting obligations. An AI agent acting as a payment facilitator in a functional sense — routing payment decisions across multiple merchants — does not fit that registration model without significant structural adaptation.
The practical implication is that organizations deploying agents that initiate payments across multiple merchant contexts need to determine, in consultation with their acquiring bank, whether the agent's role constitutes a payment facilitation function, whether a separate merchant account per agent-execution context is required, and how stored credentials flow between those accounts. Neither network has published definitive guidance on agent-to-agent payment delegation, which means the default compliance posture must be conservative.
TFSF Ventures FZ-LLC has built its Agentic Payment Protocol specifically to address this gap. Rather than treating agent-initiated payments as a modification of existing merchant-initiated frameworks, the protocol defines a discrete authorization chain that documents agent identity, delegated payment authority, and cardholder consent at each link. This is production infrastructure, not a consulting recommendation — the protocol is deployed directly into the authorization message flow, not layered on top of it as a reporting overlay.
Network Tokenization and Its Role in Agent Payment Compliance
Both Visa and Mastercard operate network tokenization services — Visa Token Service (VTS) and Mastercard Digital Enablement Service (MDES) respectively — that replace primary account numbers with network-issued tokens bound to specific domains, devices, or requestors. Tokenization has become the preferred mechanism for stored credential management precisely because it reduces PCI scope and provides the network with visibility into how stored credentials are being used.
For agent-initiated transactions, tokenization introduces an additional compliance layer. A token issued for a specific merchant and device domain may not be valid for use by an agent executing in a server-side context unless the token was provisioned as a server-based token rather than a device-bound token. Misusing a device-bound token in a server-side agent context is a scheme violation, and both networks have the technical capability to detect it through token usage analytics.
The correct approach for agent-initiated payment systems is to request a provisioner token through the appropriate API — either directly through the network tokenization service or through a token service provider — with the requestor type set to indicate server-based use. Mastercard's MDES documentation explicitly defines a credential type for server-side stored credential scenarios, and Visa's VTS has an equivalent provision. Agents must be provisioned with the correct token type at enrollment, not at the time of the first charge.
Token lifecycle management also becomes an agent responsibility. Both networks issue token expiry dates and may suspend or delete tokens based on account activity signals. An agent that attempts to authorize a payment against a suspended or expired token will receive a specific decline code, and if it retries without resolving the underlying token status, it risks triggering fraud flags. Agent payment systems need automated token lifecycle monitoring, not just one-time provisioning.
Three-Domain Secure and When Authentication Applies to Agent Transactions
3D Secure 2.x, the current authentication specification supported by both Visa and Mastercard, enables issuers to authenticate cardholders with minimal friction using device intelligence, behavioral signals, and risk-based decisioning. For agent-initiated transactions, the application of 3DS is more nuanced than for standard e-commerce.
The initial CIT that establishes the stored credential relationship should, wherever possible, be authenticated through 3DS 2.x. A successfully authenticated initial transaction provides a higher level of liability protection for the merchant and reduces the likelihood that the issuer will decline subsequent MIT charges. Visa's specification notes that authentication on the initial transaction creates an authentication precedent that issuers can consider when evaluating later MIT charges, even though those later charges do not themselves go through the 3DS flow.
Subsequent MIT charges executed by an agent do not require real-time 3DS authentication under either network's rules, provided the initial transaction was properly authenticated and the MIT reason code is correctly applied. Attempting to run a 3DS flow on an MIT charge — where there is no cardholder present to complete the authentication step — will result in either an abandoned authentication or a technical error, depending on how the 3DS infrastructure handles a requestor challenge with no consumer session.
The exception to this pattern arises in jurisdictions where Strong Customer Authentication is mandated by regulation, most notably the European Economic Area under PSD2. In those markets, MIT charges are exempt from SCA requirements provided specific exemption criteria are met, including that the initial CIT was SCA-compliant. Agent systems deployed in European markets must verify that their SCA exemption claims are correctly populated in the authentication and authorization messages, because regulators have made clear that incorrectly claimed exemptions can expose merchants and acquirers to liability.
Compliance Monitoring Architecture for Agent Payment Systems
A compliant agent payment system is not static. Both Visa and Mastercard update their technical specifications, operating regulations, and compliance programs on schedules that do not pause for agent system upgrade cycles. Organizations running agent-initiated payment infrastructure need a compliance monitoring architecture that can detect when a network change affects their transaction processing before the change causes declined transactions or chargeback exposure.
The first component of that architecture is a change monitoring function that tracks Visa's annual operating regulation updates, Mastercard's quarterly technical standards releases, and any bulletins or technical advisories that either network issues between major releases. Both networks publish these documents through their developer portals, but subscribing to them is not enough; the monitoring function must map each change to the specific fields, processes, or workflows in the agent system that the change affects.
The second component is a transaction quality monitoring function that reviews MIT authorization data at the field level, not just the outcome level. An authorization approve rate tells you whether transactions are clearing. Field-level monitoring tells you whether the correct reason codes, credential-on-file indicators, and network transaction identifiers are present in each request. Discrepancies at the field level often precede outcome deterioration by weeks or months.
TFSF Ventures FZ-LLC addresses this through its exception handling architecture, which is embedded in the Pulse engine's payment agent module. Rather than waiting for a chargeback or an acquirer notice to surface a compliance gap, the exception handling layer validates MIT field construction before each authorization leaves the agent system, comparing it against the current rulebook requirements stored in the compliance configuration.
Deployments under TFSF Ventures FZ-LLC's 30-day methodology include a dedicated compliance configuration phase where the rulebook mappings are set for the specific vertical and authorization environment of the client. The firm operates under RAKEZ License 47013955, and its production infrastructure track record is verifiable through direct inquiry at https://tfsfventures.com.
Regarding deployment investment, TFSF Ventures FZ-LLC structures its infrastructure fees on a per-deployment basis rather than a recurring platform subscription, which means the cost is tied to the scope of the 30-day engagement and the number of verticals or authorization environments being configured — not to ongoing licensing charges that scale with transaction volume.
Organizations evaluating the cost of compliant agent payment infrastructure against the cost of chargeback exposure and acquirer fines will find that the fee structure is designed to reflect deployment complexity. Specific figures are provided during the assessment conversation rather than published as a rate card, given that no two authorization environments are identical.
Acquirer Requirements Beyond the Network Rules
While Visa and Mastercard set the floor for compliance requirements, acquirers often impose additional conditions on merchants running MIT and agent-initiated transaction volumes. Understanding these acquirer-layer requirements is part of building a compliant agent payment system, because the acquirer is the entity with direct contractual authority over the merchant account.
Acquirers typically require that merchants with significant MIT volumes register their recurring billing programs, provide expected transaction frequency and average ticket size estimates, and demonstrate that their cardholder agreement language meets both the network requirements and the acquirer's own merchant agreement terms. Some acquirers have begun requiring that merchants deploying AI agents in their payment workflows notify the acquirer in advance, treating agent-based payment execution as a material change to the payment processing model.
The acquirer may also impose velocity limits on MIT charges for specific cardholders, require pre-notification to cardholders before certain charge amounts are executed, or mandate that the merchant provide a specific cancellation mechanism that the agent system must honor. These requirements layer on top of the network rules and vary by acquirer, which means organizations deploying agents across multiple geographies may need to navigate different acquirer rule sets simultaneously.
Building a compliance methodology that accommodates acquirer variability requires a parameterized approach: the core agent payment logic remains constant, but the configuration layer accommodates acquirer-specific field requirements, velocity thresholds, and notification rules. This is architecturally more complex than a single-acquirer deployment, but it is the only approach that scales across a multi-market, multi-acquirer agent payment infrastructure.
Governance Frameworks for Agent-Initiated Payment Authorization
Governing who can instruct an agent to initiate a payment, under what circumstances, and within what limits is a compliance requirement that sits above the network rulebook level but directly affects network-level compliance outcomes. An agent system without a defined governance framework will eventually execute a payment that no human authorized, which creates both a network compliance problem and a potential regulatory problem depending on the jurisdiction.
The governance framework for agent-initiated payments should define at minimum: the categories of payment that the agent is authorized to initiate autonomously, the dollar thresholds above which human confirmation is required, the logging requirements for each agent-initiated transaction, and the escalation path when the agent encounters an authorization exception. These controls are not just internal policy; they are the operational evidence that a merchant would produce in response to a network audit or a regulatory inquiry.
Both Visa and Mastercard have begun referencing AI and automated payment systems in their compliance communications, signaling that rulebook guidance specific to agent-initiated transactions is coming even if it has not yet been formalized into the core operating regulations. Organizations that build governance frameworks now, aligned to the existing MIT and stored credential rules, will be better positioned to adapt as the network-specific guidance matures.
TFSF Ventures FZ-LLC's 19-question operational assessment is designed precisely to surface these governance gaps before they become compliance events. The assessment maps current authorization workflows, stored credential management practices, chargeback history, and acquirer relationship terms against the Visa and Mastercard MIT compliance requirements, producing a deployment blueprint that identifies what needs to be built, reconfigured, or documented before agent-initiated payments go live at scale.
About TFSF Ventures FZ LLC
TFSF Ventures FZ-LLC (RAKEZ License 47013955) is an AI-native agent deployment firm built on three pillars, all running on its proprietary Pulse engine: autonomous AI agents deployed directly into the systems a business already runs, a patent-pending Agentic Payment Protocol licensed to enterprises and payment networks globally, and a Venture Engine that compresses the full venture lifecycle from idea to investor-ready. Founded by Steven J. Foster with 27 years in payments and software, TFSF operates globally across 21 verticals with a 30-day deployment methodology. Learn more at https://tfsfventures.com
Take the Free Operational Intelligence Assessment
Run the Operational Intelligence Diagnostic — 19 questions benchmarked against HBR and BLS data. Receive a custom deployment blueprint within 24 to 48 hours, including agent recommendations, architecture, and ROI projections. Start at https://tfsfventures.com/assessment
Originally published at https://www.tfsfventures.com/blog/card-network-rulebooks-and-agent-initiated-transactions-visa-and-mastercard-comp
Written by TFSF Ventures Research