03.08 Velocity Limits

Status: draft for discussion

1. Goal

Velocity limits restrict transaction activity by important business metrics.

2. Where Limits Apply

Velocity limits apply on SUB MID / SUB MID AGGREGATOR level.

3. Metrics Required in the MVP

The MVP must support limits by:

• number of successful transactions;
• number of unsuccessful transactions;
• amount of successful transactions in EUR;
• amount of unsuccessful transactions in EUR.

4. Limit Scope

Limits must work by:

• SUB MID / SUB MID AGGREGATOR;
• customer/user reference;
• selected time window.

5. When a Limit Is Exceeded

If a limit is exceeded:

• the system tries a fallback option if fallback is enabled;
• timeline shows that the option was rejected because of velocity;
• merchant does not see hidden provider details;
• if no suitable options remain, the transaction receives a rejected result.

6. Business Context

Velocity limits are important for deposits because they affect both conversion and risk control.

The product should make it clear:

• which limit rejected the execution option;
• whether fallback was tried;
• whether the final rejection was caused by all options being unavailable;
• what merchant can safely see;
• what platform can investigate in detail.

Merchant users should see a safe business reason.

Platform users should be able to see the exact limit that caused rejection if their access allows it.