Flows
The whole protocol, end to end
The load generator runs the complete payment and data flows, with PKCE, consent and polling. There is no shortcut route in the simulator. The only way to get a 200 is to navigate the protocol correctly.
Scale report
April 2026The measurements in this report were taken in the same environment, with complete FAPI-BR flows and real latency. It is what runs in production today.
Realistic scenario · Apr 2026
SnapshotThroughput
51,927
req/s
Total requests
778,905
Error rate
0.007
%
P50
217
ms
P99
1,578
ms
VUs (peak)
53,753
We handle 1.9x more load than the entire Open Finance ecosystem.
52,000 req/s is what our regulated layer delivers under realistic load, calibrated with production telemetry. Without losing performance, and with 8 errors in 775,344 requests.
The ceiling measured at 52,000 req/s belongs to the current configuration, not to the architecture. The layer that saturates under synthetic load is the mTLS termination at the load balancer, not the proxy application.
1,200x the capacity of the largest payment initiator.
The ecosystem's largest initiator generated 26.06 million requests in its peak week of the reference period. At the throughput our infrastructure delivers today, that entire volume goes through in under nine minutes of operation.
The path to more capacity: LB sharding, incremental, without changing a line of the application.
How it was measured
Complete FAPI-BR flows.
Each virtual user ran the entire protocol: payment consent, PAR, authorization, client credentials, auth code, Pix initiation, polling. Real PKCE, real consent IDs and Bearer tokens with real scope.
Latency
Calibrated with real telemetry
The simulator answers with a piecewise-linear distribution anchored on the quantiles we measure in production: p50 at 130 ms, p90 at 350 ms, p99 at 1,350 ms. The reported result is under realistic load.
Infra
Proxy pool of 120 instances
120 m8i.large instances behind an ALB with mTLS termination. 16 m8i.large run the Open Finance simulator. Two c5.9xlarge run k6 in parallel as the load generator.
- 240 aggregate vCPUs on the proxy
- Managed ALB • round-robin
- k6 v1.7.1 • constant-arrival-rate
Every system has a ceiling. Ours is known, and the way out is already mapped.
The infrastructure as it stands would, in principle, absorb the normal load of the entire Open Finance ecosystem at once. Serving a single large customer leaves substantial headroom, even before any architectural re-scaling.
Ceiling • 52,000 req/s
mTLS saturation at the load balancer
Around 52k req/s, failures appear that scaling the proxy horizontally does not fix. The cause is the mTLS handshake cryptographic capacity at the load balancer. The bottleneck lives at the edge, not in the application.
- 502 when the LB stops accepting new connections
- 401 when the handshake times out
- The proxy itself runs with headroom, no sign of saturation
The way out • Linear sharding
Load balancer sharding
The architectural path is pre-planned: multiple independent load balancers behind an L4 distributor. Each additional shard adds mTLS termination capacity linearly.
- Linear scale: n shards, n× capacity
- Zero changes to the proxy application
- Incremental deploy, no service interruption
- Transparent to the end customer
Download the full report.
English text, 38 pages, classified Confidential. Includes test topology, latency distribution, status codes, mTLS bottleneck analysis, comparison with the entire ecosystem, and the sharding roadmap.
Issued in April 2026Included in the report
- Methodology and topology
- Results, status codes and latency
- mTLS bottleneck analysis and ecosystem comparison
- Sharding roadmap
- Ecosystem estimate and sensitivity