Velocity Check
Use declined-provisioning activity to inform your tokenization rules.
Velocity Check detects repeated declined provisioning activity and provides the configured result for decisioning. Your rules choose the outcome; a positive velocity result does not independently force a decline. Agree the service and its parameters with the implementations team.
| Scope | What is monitored | Configuration |
|---|---|---|
| PAN | Declined attempts for the same funding card | Attempt threshold, monitoring window, cooldown duration |
| Token requestor ID | Declined activity associated with a requestor | Monitoring scope, decline threshold or rate, window, cooldown duration |
For example, repeated invalid-card-data attempts can put a card into a configured cooldown. Your rules determine how the resulting signal affects a subsequent provisioning request. Define the requestor scope carefully during implementation so the control matches your programme.
In your notifications
When the service applies, its result accompanies the scheme payload in ADDITIONAL_MESSAGE_DATA. Use it with the decisioning result to understand the outcome. The Mastercard example shows how enrichment sits alongside native fields.
Requesting changes
Review declined-provisioning patterns with the implementations team. Agree a threshold and duration suitable for your programme, then test both the triggered control and normal activity. Example values are not universal production defaults.
Updated 20 days ago