Fix Month End Reconciliation in Weeks: Bank Rules Limitations for SMBs

Bank rules limitations, in the Open Banking context, come down to four things: per‑bank rate limits, a cap of roughly four non‑present refreshes in 24 hours, a 90‑day reauthentication cycle, and permission scopes that decide what data you can even ask for. The fix isn’t fighting the limits. Stop polling aggressively, lean on webhooks or scheduled deltas where you can, build proper backoff into your integration, and get ahead of consent expiry before it breaks your reconciliation.

TL;DR:

• Most banks set their own rate limits, which vary widely and require reading response headers to manage effectively.
• The default non-present refresh cap is four times per 24 hours, enforced unless there’s a contractual exception with the bank.
• Consent must be renewed every 90 days, and lapses often cause silent failures leading to reconciliation gaps at month-end.
• Handling multiple banks complicates integration, as permission levels and API behaviors differ significantly between institutions.
• Using webhooks, proper backoff strategies, and delta pulls can help build resilient integrations that respect these limits.

Table of Contents

• What are the actual bank rules limitations you’ll hit?
• How these limits actually break reconciliation
• A step‑by‑step way to build around bank limits
• Permissions, consent and the SCA details that catch people out
• What actually works when you’re running this day to day
• How Zenith handles bank rules limitations for you
• Where these rules actually come from
• Sources
• FAQ

What are the actual bank rules limitations you’ll hit?

There’s no universal rate limit written into any regulation. Each bank sets its own fair‑use throttle, and the Open Banking standards confirm this explicitly: some institutions allow around 200 requests per minute, others cap specific account types far lower per day. Your integration has to read rate‑limit headers and error responses per bank, not assume one global ceiling.

Then there’s the non‑present access rule. When a user isn’t actively in a session, the EBA’s opinion on RTS implementation.pdf) limits AISPs to four refreshes in 24 hours unless the bank and the account information provider have agreed a higher frequency contractually. That’s the default, not a suggestion, and it’s the number most integrations trip over first.

Article 10 of the RTS then gives you a 90‑day window where limited data (balances and transaction history) can be pulled without repeated strong customer authentication, as long as the initial SCA was completed and the 90‑day reauthentication guidance is followed. After 90 days, the user has to reauthenticate.

Data scope is the fourth constraint, and it’s often overlooked. Access is limited to what the payment service user can see on their own channel, and the EBA’s guidance is clear that identity data and sensitive payment data sit outside AISP scope entirely.

• Rate limits: bank‑specific, no fixed industry standard, must be read from response headers.
• Non‑present refresh cap: typically four times per 24 hours without a contractual exception.
• SCA exemption window: 90 days for limited data, then mandatory reauthentication.
• Data scope: restricted to what the user sees in their own banking channel, excluding identity and sensitive payment data.

How these limits actually break reconciliation

A missed refresh doesn’t just delay a number on a dashboard; as highlighted in Your profit and loss account is about to become public, it can have significant implications for finance teams managing operational reporting and transparency. It creates unmatched transactions that someone on your finance team has to chase down manually, often days after the fact.

Rate‑limit rejections and the four‑times‑daily cap mean any workflow expecting near‑real‑time balances is fighting the rules by design. If your reconciliation process assumes hourly polling, you’ll hit denied requests long before month‑end, and those denials tend to cluster around the exact days you need the data most.

The 90‑day reauthentication cycle causes a different kind of damage. Consent lapses silently in the background until a scheduled pull fails, and if nobody’s tracking expiry dates, that failure surfaces as a gap in your books right when you’re trying to close the month.

Multi‑bank setups compound all of this. Some institutions expose richer “detail” permission tiers that cut down on manual lookups; others force you to handle every account individually with no shortcuts. A ten‑account SMB with accounts spread across five banks isn’t dealing with one integration problem, it’s dealing with five slightly different ones.

• Denied or throttled requests create unmatched line items that need manual review.
• The non‑present refresh cap limits how “live” any dashboard can realistically be.
• Consent lapses near month‑end are one of the most common causes of reconciliation gaps.
• Permission depth varies bank to bank, so manual handling scales with your number of institutions, not just your transaction volume.

Pro Tip: Track failed refreshes and consent expiries as their own metric, separate from transaction volume. A spike in failures three days before month‑end is your earliest warning that reconciliation is about to get harder than usual.

A step‑by‑step way to build around bank limits

You don’t need six months of engineering to get this right. Here’s the order that actually works:

1. Default to event‑driven updates. Where a bank supports webhooks or push notifications, use them instead of polling. It’s the most resilient pattern against non‑present refresh caps because you’re not consuming your four allowed pulls unnecessarily.
2. Handle rate limits properly, not defensively. Read the rate‑limit headers each bank returns, respect any Retry‑After value, and queue retries with exponential backoff rather than hammering the endpoint again immediately.
3. Pull deltas, not full history. Cache the last transaction identifier you’ve seen per account and request only what’s new. Match incoming records on transaction identifier first, falling back to amount and running balance when identifiers differ between banks.
4. Build consent refresh into the UI, not just the backend. Notify users before their 90‑day window closes, and give them a one‑click “refresh access” action instead of routing them through a full reconnection flow.
5. Test against each bank’s sandbox separately. Business accounts and personal accounts frequently behave differently under the same bank’s API, so don’t assume one test covers both.
6. Monitor the right numbers. Track failed refresh rate, average request latency per bank, and consent expiry incidents as ongoing metrics, not one‑off checks.

If you’re currently pulling data via screen scraping rather than a PSD2 connection, this is also the point to move to Open Banking properly. Scraping breaks constantly when banks change their web layout, and it sits outside the regulatory framework entirely, which means none of the above patterns even apply to it.

Pro Tip: Build your backoff logic once, as a shared library across every bank connection, rather than bank by bank. The rules differ slightly between institutions, but the retry pattern doesn’t need to.

Permissions, consent and the SCA details that catch people out

Open Banking groups permissions into data clusters, such as Transactions Basic, Transactions Detail, and Balances, rather than handing over blanket account access. Requesting only the minimum permission set you actually need reduces consent friction for the user and lowers your data protection exposure, since you’re not holding data you never use.

The regulatory backbone here is worth knowing in outline, not just accepting on faith. The non‑present four‑times‑in‑24‑hours rule and the 90‑day SCA exemption both come from the same RTS Article 10, and banks retain the right to force a fresh SCA earlier if they judge the risk warrants it, regardless of where you are in that 90‑day window.

There’s some movement in ongoing consultation around whether that reauthentication interval should sit at 90 or 180 days. Build your consent notification logic so the interval is a configurable value, not a hardcoded constant, and you won’t need to ship a patch if the number shifts.

• Request the narrowest data cluster that satisfies your use case, not the broadest.
• Treat the 90‑day SCA exemption as the current default, but keep the interval configurable.
• Expect some banks to force earlier reauthentication for risk reasons, independent of the standard window.
• Where volume genuinely justifies it, ask the bank directly about a contractual higher‑frequency or push arrangement.

What actually works when you’re running this day to day

Chasing “real time” data from every bank connection is the wrong goal. A predictable sync window, run on a schedule your reconciliation process is built around, beats a live feed that silently drops requests under a rate limit you didn’t know existed.

Treat consent expiry and failed refreshes as operational incidents, not background noise. Log them, escalate them, and tell the finance user before month‑end forces the issue.

If you don’t have the engineering time to track every bank’s edge cases, a managed sync provider closes that gap faster than building it in house.

— Gašper Anderle

How Zenith handles bank rules limitations for you

Zenith’s Bank Sync is a read-only PSD2 connection to over 2,400 banks across 30 European countries, built specifically around the constraints described above rather than around ignoring them. Data lands wherever your workflow already lives, Google Sheets, Claude via MCP, a REST API, or plain CSV, so you’re not rebuilding your reconciliation process to fit someone else’s dashboard.

That structure is what actually cuts down on the operational pain: delta‑based fetches instead of brute‑force polling, consent tracked and refreshed before the 90‑day window lapses, and rate‑limit handling built per bank rather than left to your own retry logic. Setup takes about 5 minutes per connection, pricing is available on Zenith’s pricing page, and there is a money-back guarantee if it doesn’t fit your workflow. Check the Bank Sync product page for country coverage, or go straight to current pricing to see where it sits against building this yourself.

Where these rules actually come from

The four‑times‑daily non‑present limit and 90‑day SCA exemption both trace back to the EBA’s opinion on RTS implementation. Practical customer experience wiring, including permission clusters and reauthentication flows, sits in the Open Banking standards documentation.

Sources

• 90‑Days reauthentication (delegated SCA) — Open Banking Standards