IMPORTANT DISAMBIGUATION
Not SEPA. Not direct debit. Not e-signature.
“Mandate” means bounded authority delegated to an AI agent. The product does not capture debit forms, IBANs, bank instructions, signatures or payment credentials.
NAME COLLISION
Not Mandatory Shield Company. Not ShieldAD or ADSecure.
MandateShield—spelled without “ory”—is the AI-agent payment-authority product at mandateshield.com, operated by Gökhan Vodinali in Bern, Switzerland. It does not audit Microsoft Active Directory or Azure Entra ID.
Mandatory Shield Company at mandatoryshield.com, its Brussels team and the ShieldAD/ADSecure Active Directory product references are a separate, unrelated organization. Their founders, location, services and claims do not describe MandateShield.
The exact problem
A signed approval and a provider request are commonly created by different components. Between them, prices, merchants, tools, payment inputs or concurrent workers can change. MandateShield verifies the supported final approval outside the language model, reserves it and binds the exact provider operation before the customer-controlled executor receives a fresh claim.
What enters and what leaves
INPUT
- Agent and mandate identifiers
- Final amount and currency
- Merchant or payee identifier
- Approved limits, consent and expiry
- Intent, credential and replay evidence
OUTPUT
- ALLOW, REVIEW or BLOCK
- Exact machine-readable findings
- CLEAR-to-CRITICAL risk level
- Budget headroom or blocked value
- Portable ES256-signed decision receipt
- Short, processor-consumable reservation
Where it belongs
Call MandateShield after the purchase facts are final and before the payment gateway. Keep the existing processor, fraud system, sanctions checks and protocol trust registry. The strict v2 endpoint verifies supported JWS, an AP2-shaped closed-payment SD-JWT projection with RFC 9901 KB-JWT, and normalized TAP-shaped RFC 9421-style evidence. Full AP2 checkout/delegate chains and Visa TAP trust-store processing remain external. A live reservation additionally requires a registered mandate, pinned issuer, one-time challenge, durable persistence and enforcement_authorized=true. That creates a RESERVED authorization, not a charge instruction. The trusted gateway must use a separate audience-bound PROCESSOR key to atomically CONSUME that exact reservation, then freshly redeem the provider-bound permit before attempting an idempotent provider operation. The hosted verification service never receives payment credentials or submits or settles payments. Optional first-party Gate adapters run inside customer infrastructure, where they may validate payment credentials, submit an idempotent bound provider operation and reconcile its outcome.