Digital banking API load: what we build for peak traffic
Digital banking traffic arrives in bursts, and the core banking connector behind the app often cannot scale the way app servers can. Agnotic Technologies builds the API layer, caches and connectors to your requirements.
Last reviewed by the Agnotic Technologies engineering team
What sets the API load a digital banking platform must handle?
Digital banking API load is set by the busiest second: logins, balance checks, transfers, bill payments, alerts and third-party data requests arriving together, multiplied by the calls each action makes to the core banking system. Agnotic Technologies builds API layers, caches and core connectors so that this peak reaches the core in a form it can carry.
Where does banking API load cause trouble?
Most incidents trace back to the gap between what the app can absorb and what the core behind it can.
The core connector does not scale like the app
The digital layer can add servers when traffic rises. The core and its connector may have a fixed pool of sessions, a vendor-set throughput or batch windows when inquiries slow down.
One tap becomes several core calls
A login loads the account list, and a transfer needs a funds check, a hold or posting and a confirmation. Edge traffic understates what reaches the core.
Reads that could be cached hit the core
Account lists, balances, older history pages and generated statements often go straight to the core, using capacity that money movement needs.
Aggregator traffic ignores daytime patterns
Third parties may refresh many accounts in scheduled runs that set the busiest hour on their own. Under 12 CFR Part 1033, frequency limits must be reasonable and non-discriminatory, so this load cannot simply be throttled away.
Retries arrive when the core is slowest
Timeouts trigger retries, which add load exactly when the core is struggling. Without idempotency, a retried transfer can post twice.
Other systems share the same core
End-of-day processing, batch jobs, branch and call center systems all draw on the core alongside digital traffic.
What do we build for banking API load?
Agnotic Technologies builds the layer between your customers, third parties and your core, to your requirements and your core vendor's interfaces.
API gateway with per-client rate limits
Limits per app client and per third party that answer excess requests with 429 Too Many Requests and a Retry-After header.
Read caches and replicas
Caches with short expiry for account lists and balances, and stored copies of older history pages and generated statements, so read traffic stays off the core.
Core banking connectors
Adapters for the interfaces your core vendor exposes, with connection pooling, timeouts set per call type and latency alerts.
Payment queues with idempotency keys
Transfers and bill payments placed on a queue with an idempotency key, so a retry after a timeout never posts the same payment twice.
A separate third-party data API
A documented, metered interface for authorized third parties, with monthly reporting on proper responses against total requests.
Event-driven alerts
Balance and posting alerts driven by an event stream from the core where one is available, instead of polling jobs that add inquiry load.
Load testing and capacity dashboards
Load tests of the whole path at the busiest second plus the margin your risk team sets, and dashboards that show edge load and core load side by side.
Which customer actions reach the core banking system?
The same tap in the app can be one request at your API edge and several calls behind it. Trace each action once in a test environment to see the real sequence.
| Action | What the app asks for | What the core may be asked to do | Can a cache answer it? |
|---|---|---|---|
| Login | Authenticate, then load the account list | Customer and account inquiry | The account list, for a short time |
| Balances | Current and available balance per account | Balance inquiry per account | Often, with a short expiry and a refresh button |
| Transaction history | Recent postings, one page at a time | History inquiry per page | Older pages, yes; today's postings, no |
| Transfer | Move funds between own accounts | Funds check, hold or posting, confirmation | No: every transfer must reach the core |
| Bill payment | Pay a saved payee | Funds check and debit, often through a payments hub | No |
| Alert | Push or SMS when a balance or posting rule fires | Event feed from the core, or a polling job | Only if alerts are driven by an event stream |
| Statement download | A PDF for a past period | Document archive request | Yes, once generated |
| Aggregator request | Account, balance and transaction data for an authorized third party | The same inquiries as the customer's own reads | Often, within the data freshness you commit to |
Why does the core connector set the limit?
The digital layer can usually add servers when traffic rises. The core banking system and the connector in front of it often cannot: they may have a fixed pool of sessions, a vendor-set throughput or batch windows when inquiries slow down.
That is why capacity planning needs two figures. Edge load sizes your API gateway and app servers. Core load, after the share you answer from a cache, is the figure to compare with the connector's capacity.
If you are planning a new connector or replacing a core, our core banking modernization services page covers how that work is phased.
How do you size the connector, rate limits and queues?
Get the connector's sustained requests per second from your core vendor, or measure it with a load test against a test core.
Model peak load for today's customers, then again for the customer numbers in your growth plan.
If peak core calls approach the connector's capacity, move read-only calls to a cache or read replica first, starting with the actions in the table above marked as cache candidates.
Set a rate limit per client and per third party, and answer requests over the limit with 429 Too Many Requests and a Retry-After header.
Put money movement behind a queue with idempotency keys, so a retry after a timeout never posts a transfer twice.
Load test the whole path at your busiest second plus the margin your risk team sets, with alerts on connector latency.
How should aggregator traffic be treated?
Third-party data access needs its own plan because it does not follow your customers' daytime pattern. Aggregators may refresh many accounts in scheduled runs, which can set the busiest hour on their own.
Under the personal financial data rights rule in 12 CFR Part 1033, a covered data provider's developer interface must meet performance and access cap requirements. Frequency limits must be reasonable and non-discriminatory, so plan capacity for this traffic rather than throttling it away.
A separate, documented API for third parties is easier to meter and protect. Our scalable API platform for fintech page describes that design.
How does Agnotic build a banking API layer?
We start by tracing each customer action against your core in a test environment and reading your core vendor's interface limits. The gateway, caches, queues and connector are then designed around the busiest second you expect.
Card authorization traffic usually runs through card networks and processors, so we plan it apart from app traffic. Features for the app itself are covered on our digital banking platform page.
Which rules and standards shape banking API capacity?
Short facts from the regulation and the internet standards behind rate limiting, checked against the primary source on 21 Oct 2026.
12 CFR 1033.311(c)(1) says a developer interface's performance cannot be commercially reasonable unless proper responses divided by total requests for covered data are at least 99.5 percent in each calendar month, excluding scheduled downtime.
Source: 12 CFR 1033.311, Requirements applicable to developer interface (eCFR)12 CFR 1033.311(d) says a data provider must not unreasonably restrict how often it receives or responds to requests from an authorized third party, and any frequency restrictions must be applied in a non-discriminatory way.
Source: 12 CFR 1033.311(d), Access caps (eCFR)RFC 6585 defines HTTP status code 429 Too Many Requests for a user that has sent too many requests in a given amount of time, and says the response may include a Retry-After header.
Source: IETF RFC 6585, Additional HTTP Status CodesRFC 9110 defines the Retry-After header field, which servers send to say how long a client ought to wait before making a follow-up request, as an HTTP date or a number of seconds.
Source: IETF RFC 9110, HTTP Semantics, section 10.2.3
Trusted by global innovators
Where should you go next?
- Digital banking platformOnline and mobile banking built around your core.
- Core banking software developmentAccounts, postings and ledgers for banks and lenders.
- Core banking modernization servicesPhased replacement and connector work around a legacy core.
- Scalable API platform for fintechGateways, rate limits and partner APIs.