[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-article-en-bank-rules-limitations":3,"blog-related-en-bank-rules-limitations":17},{"slug":4,"locale":5,"title":6,"excerpt":7,"og_image_url":7,"hero_image_url":8,"reading_time":7,"published_at":9,"tags":10,"body_md":11,"content_html":12,"meta_title":6,"meta_description":13,"json_ld_str":14,"faq_json_ld_str":15,"author":7,"other_locales":16},"bank-rules-limitations","en","Fix Month End Reconciliation in Weeks: Bank Rules Limitations for SMBs",null,"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789782010033_Analyst-reviewing-an-open-banking-connection.jpeg","2026-09-21T02:30:19.444+00:00",[],"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.\n\n***\n\n> **TL;DR:**\n>\n> - Most banks set their own rate limits, which vary widely and require reading response headers to manage effectively.\n> - The default non-present refresh cap is four times per 24 hours, enforced unless there’s a contractual exception with the bank.\n> - Consent must be renewed every 90 days, and lapses often cause silent failures leading to reconciliation gaps at month-end.\n> - Handling multiple banks complicates integration, as permission levels and API behaviors differ significantly between institutions.\n> - Using webhooks, proper backoff strategies, and delta pulls can help build resilient integrations that respect these limits.\n\n***\n\n## Table of Contents\n\n- [What are the actual bank rules limitations you'll hit?](#what-are-the-actual-bank-rules-limitations-youll-hit)\n- [How these limits actually break reconciliation](#how-these-limits-actually-break-reconciliation)\n- [A step‑by‑step way to build around bank limits](#a-stepbystep-way-to-build-around-bank-limits)\n- [Permissions, consent and the SCA details that catch people out](#permissions-consent-and-the-sca-details-that-catch-people-out)\n- [What actually works when you're running this day to day](#what-actually-works-when-youre-running-this-day-to-day)\n- [How Zenith handles bank rules limitations for you](#how-zenith-handles-bank-rules-limitations-for-you)\n- [Where these rules actually come from](#where-these-rules-actually-come-from)\n- [Sources](#sources)\n- [FAQ](#faq)\n\n## What are the actual bank rules limitations you'll hit?\n\nThere'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.\n\nThen 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.\n\nArticle 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](https:\u002F\u002Fstandards.openbanking.org.uk\u002Fcustomer-experience-guidelines\u002Fappendices\u002F90-days-reauthentication-delegated-sca\u002Flatest\u002F) is followed. After 90 days, the user has to reauthenticate.\n\nData 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.\n\n- Rate limits: bank‑specific, no fixed industry standard, must be read from response headers.\n- Non‑present refresh cap: typically four times per 24 hours without a contractual exception.\n- SCA exemption window: 90 days for limited data, then mandatory reauthentication.\n- Data scope: restricted to what the user sees in their own banking channel, excluding identity and sensitive payment data.\n\n## How these limits actually break reconciliation\n\nA missed refresh doesn't just delay a number on a dashboard; as highlighted in [Your profit and loss account is about to become public](https:\u002F\u002Fkeystonefa.co.uk\u002Fpost\u002Fyour-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.\n\nRate‑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.\n\nThe 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.\n\nMulti‑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.\n\n- Denied or throttled requests create unmatched line items that need manual review.\n- The non‑present refresh cap limits how \"live\" any dashboard can realistically be.\n- Consent lapses near month‑end are one of the most common causes of reconciliation gaps.\n- Permission depth varies bank to bank, so manual handling scales with your number of institutions, not just your transaction volume.\n\n**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.*\n\n## A step‑by‑step way to build around bank limits\n\nYou don't need six months of engineering to get this right. Here's the order that actually works:\n\n1. **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.\n2. **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.\n3. **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.\n4. **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.\n5. **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.\n6. **Monitor the right numbers.** Track failed refresh rate, average request latency per bank, and consent expiry incidents as ongoing metrics, not one‑off checks.\n\nIf you're currently pulling data via screen scraping rather than a PSD2 connection, this is also the point to [move to Open Banking](https:\u002F\u002Fzenith-books.com\u002Fblog\u002Fen\u002Fopen-banking-vs-screen-scraping) 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.\n\n**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.*\n\n## Permissions, consent and the SCA details that catch people out\n\nOpen 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.\n\n![Selective open banking permission clusters](https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789781985692_Selective-open-banking-permission-clusters.jpeg)\n\nThe 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.\n\nThere'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.\n\n- Request the narrowest data cluster that satisfies your use case, not the broadest.\n- Treat the 90‑day SCA exemption as the current default, but keep the interval configurable.\n- Expect some banks to force earlier reauthentication for risk reasons, independent of the standard window.\n- Where volume genuinely justifies it, ask the bank directly about a contractual higher‑frequency or push arrangement.\n\n## What actually works when you're running this day to day\n\nChasing \"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.\n\n![What actually works when you're running this day to day — overview diagram](https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789782101690_What-actually-works-when-you-re-running-this-day-to-day-overview-diagram.jpeg)\n\nTreat 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.\n\nIf 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.\n\n> *— Gašper Anderle*\n\n## How Zenith handles bank rules limitations for you\n\nZenith'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.\n\n![Zenith](https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1784870754037_zenith-books.jpg)\n\nThat 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](https:\u002F\u002Fzenith-books.com\u002Fbank-sync) for country coverage, or go straight to [current pricing](https:\u002F\u002Fzenith-books.com\u002Fpricing) to see where it sits against building this yourself.\n\n## Where these rules actually come from\n\nThe 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.\n\n## Sources\n\n- [90‑Days reauthentication (delegated SCA) — Open Banking Standards](https:\u002F\u002Fstandards.openbanking.org.uk\u002Fcustomer-experience-guidelines\u002Fappendices\u002F90-days-reauthentication-delegated-sca\u002Flatest\u002F)\n\n## FAQ\n\n### How often can I refresh bank data without a live session?\n\nNon‑present access is generally capped at four refreshes in 24 hours under the EBA's RTS guidance, unless the bank has agreed a higher frequency by contract. Active, in‑session requests aren't bound by this same cap.\n\n### What triggers a forced reauthentication before 90 days?\n\nBanks can require strong customer authentication earlier than the standard 90‑day window if they detect risk factors on the account or connection. Outside of that, initial SCA covers limited data access for the full 90 days.\n\n### Do webhooks replace polling entirely?\n\nWhere a bank supports webhooks or push notifications, they're the more resilient option and reduce how often you need to poll. Not every bank offers this, so most integrations still need scheduled delta pulls as a fallback.\n\n### How do I avoid hitting bank rate limits?\n\nRead each bank's rate‑limit headers, respect `Retry‑After` values, and queue retries with exponential backoff instead of retrying immediately. Zenith's Bank Sync handles this per bank automatically, which is one reason it avoids the manual retry logic most in‑house integrations need to build.\n\n### What does Zenith's Bank Sync cost per account?\n\nBank Sync is priced at €5 per account per month, with a 5‑minute setup and a 30‑day money‑back guarantee. Full plan pricing, including Starter, Growth, and Business tiers, is listed on the pricing page.\n\n## Recommended\n\n- [Bank Reconciliation Best Practices for Finance Teams](https:\u002F\u002Fzenith-books.com\u002Fblog\u002Fen\u002Fbank-reconciliation-best-practices)\n- [Month End Close Automation: Cut Days Off Your Close](https:\u002F\u002Fzenith-books.com\u002Fblog\u002Fen\u002Fmonth-end-close-automation)\n- [Multi currency reconciliation: a workflow-first playbook](https:\u002F\u002Fzenith-books.com\u002Fblog\u002Fmulti-currency-reconciliation)\n- [Finish Month End in Days: PSD2 Ready Cash Application Automation for EU SMEs](https:\u002F\u002Fzenith-books.com\u002Fblog\u002Fen\u002Fcash-application-automation)\n\nThis article is for general information only and isn't financial, tax, or legal advice.","\n    \n      \n    \u003Ch2 id=\"fix-month-end-reconciliation-in-weeks-bank-rules-limitations-for-smbs\" tabindex=\"-1\">Fix Month End Reconciliation in Weeks: Bank Rules Limitations for SMBs\u003C\u002Fh2>\n\u003Cp>\u003Cimg loading=\"lazy\" decoding=\"async\" src=\"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789782010033_Analyst-reviewing-an-open-banking-connection.jpeg\" alt=\"Analyst reviewing an open banking connection\" \u002F>\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Chr \u002F>\n\u003Cblockquote>\n\u003Cp>\u003Cstrong>TL;DR:\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Most banks set their own rate limits, which vary widely and require reading response headers to manage effectively.\u003C\u002Fli>\n\u003Cli>The default non-present refresh cap is four times per 24 hours, enforced unless there’s a contractual exception with the bank.\u003C\u002Fli>\n\u003Cli>Consent must be renewed every 90 days, and lapses often cause silent failures leading to reconciliation gaps at month-end.\u003C\u002Fli>\n\u003Cli>Handling multiple banks complicates integration, as permission levels and API behaviors differ significantly between institutions.\u003C\u002Fli>\n\u003Cli>Using webhooks, proper backoff strategies, and delta pulls can help build resilient integrations that respect these limits.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003C\u002Fblockquote>\n\u003Chr \u002F>\n\u003Cdiv data-blg-cta=\"after_tldr\" data-blg-cta-layout=\"banner\" style=\"margin:28px 0;font-family:-apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, Helvetica, Arial, sans-serif;box-sizing:border-box\">\u003Cdiv style=\"border-radius:26px;padding:min(22px,3.2vw);background:radial-gradient(circle at 100% 0%,#dbd9ef 0 150px,rgba(255,255,255,0) 151px),radial-gradient(circle at 0% 100%,#dbd9ef 0 130px,rgba(255,255,255,0) 131px),linear-gradient(180deg,#e7e6f4 0%,#f3f2fa 100%)\">\u003Cdiv style=\"background:#ffffff;border-radius:18px;box-shadow:0 12px 34px rgba(0,0,0,0.13);overflow:hidden\">\u003Cdiv style=\"padding:34px 30px;text-align:center\">\u003Cdiv style=\"margin:0 0 18px\">\u003Cspan style=\"display:inline-block;max-width:100%;box-sizing:border-box;border-radius:999px;padding:6px 13px;font-size:12px;font-weight:800;letter-spacing:0.1em;text-transform:uppercase;line-height:1.3;background:#382CA6;color:#ffffff\">Zenith\u003C\u002Fspan>\u003C\u002Fdiv>\u003Cdiv style=\"font-size:26px;font-weight:800;line-height:1.2;letter-spacing:-0.01em;color:#1f2937;margin:0\">Simplify Month End Reconciliation\u003C\u002Fdiv>\u003Cdiv style=\"width:56px;height:6px;border-radius:3px;background:#382CA6;margin:12px 0 14px;margin-left:auto;margin-right:auto\">\u003C\u002Fdiv>\u003Cdiv style=\"font-size:15px;line-height:1.55;color:#64748b;margin:0 0 24px;max-width:44em;margin-left:auto;margin-right:auto\">Zenith connects European bank data, matches transactions, and provides cash flow visibility without manual data entry.\u003C\u002Fdiv>\u003Ca href=\"https:\u002F\u002Fzenith-books.com\" style=\"display:inline-flex;align-items:center;gap:9px;border-radius:10px;font-weight:700;font-size:15px;text-decoration:none;padding:13px 22px 13px 26px;background:#382CA6;color:#ffffff\">Explore Zenith\u003Csvg width=\"17\" height=\"17\" viewBox=\"0 0 24 24\" fill=\"none\" stroke=\"#ffffff\" stroke-width=\"2.6\" stroke-linecap=\"round\" stroke-linejoin=\"round\" style=\"display:block;flex:0 0 auto\">\u003Cpath d=\"M5 12h14\">\u003C\u002Fpath>\u003Cpath d=\"m12 5 7 7-7 7\">\u003C\u002Fpath>\u003C\u002Fsvg>\u003C\u002Fa>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\u003C\u002Fdiv>\n\u003Ch2 id=\"table-of-contents\" tabindex=\"-1\">Table of Contents\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"#what-are-the-actual-bank-rules-limitations-youll-hit\">What are the actual bank rules limitations you’ll hit?\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#how-these-limits-actually-break-reconciliation\">How these limits actually break reconciliation\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#a-stepbystep-way-to-build-around-bank-limits\">A step‑by‑step way to build around bank limits\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#permissions-consent-and-the-sca-details-that-catch-people-out\">Permissions, consent and the SCA details that catch people out\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#what-actually-works-when-youre-running-this-day-to-day\">What actually works when you’re running this day to day\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#how-zenith-handles-bank-rules-limitations-for-you\">How Zenith handles bank rules limitations for you\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#where-these-rules-actually-come-from\">Where these rules actually come from\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#sources\">Sources\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"#faq\">FAQ\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"what-are-the-actual-bank-rules-limitations-youll-hit\" tabindex=\"-1\">What are the actual bank rules limitations you’ll hit?\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"https:\u002F\u002Fstandards.openbanking.org.uk\u002Fcustomer-experience-guidelines\u002Fappendices\u002F90-days-reauthentication-delegated-sca\u002Flatest\u002F\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">90‑day reauthentication guidance\u003C\u002Fa> is followed. After 90 days, the user has to reauthenticate.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Rate limits: bank‑specific, no fixed industry standard, must be read from response headers.\u003C\u002Fli>\n\u003Cli>Non‑present refresh cap: typically four times per 24 hours without a contractual exception.\u003C\u002Fli>\n\u003Cli>SCA exemption window: 90 days for limited data, then mandatory reauthentication.\u003C\u002Fli>\n\u003Cli>Data scope: restricted to what the user sees in their own banking channel, excluding identity and sensitive payment data.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"how-these-limits-actually-break-reconciliation\" tabindex=\"-1\">How these limits actually break reconciliation\u003C\u002Fh2>\n\u003Cp>A missed refresh doesn’t just delay a number on a dashboard; as highlighted in \u003Ca href=\"https:\u002F\u002Fkeystonefa.co.uk\u002Fpost\u002Fyour-profit-and-loss-account-is-about-to-become-public\" target=\"_blank\" rel=\"noopener\">Your profit and loss account is about to become public\u003C\u002Fa>, 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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Denied or throttled requests create unmatched line items that need manual review.\u003C\u002Fli>\n\u003Cli>The non‑present refresh cap limits how “live” any dashboard can realistically be.\u003C\u002Fli>\n\u003Cli>Consent lapses near month‑end are one of the most common causes of reconciliation gaps.\u003C\u002Fli>\n\u003Cli>Permission depth varies bank to bank, so manual handling scales with your number of institutions, not just your transaction volume.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>\u003Cstrong>Pro Tip:\u003C\u002Fstrong> \u003Cem>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.\u003C\u002Fem>\u003C\u002Fp>\n\u003Ch2 id=\"a-stepbystep-way-to-build-around-bank-limits\" tabindex=\"-1\">A step‑by‑step way to build around bank limits\u003C\u002Fh2>\n\u003Cp>You don’t need six months of engineering to get this right. Here’s the order that actually works:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Default to event‑driven updates.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Handle rate limits properly, not defensively.\u003C\u002Fstrong> Read the rate‑limit headers each bank returns, respect any \u003Ccode>Retry‑After\u003C\u002Fcode> value, and queue retries with exponential backoff rather than hammering the endpoint again immediately.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Pull deltas, not full history.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Build consent refresh into the UI, not just the backend.\u003C\u002Fstrong> 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.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Test against each bank’s sandbox separately.\u003C\u002Fstrong> Business accounts and personal accounts frequently behave differently under the same bank’s API, so don’t assume one test covers both.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Monitor the right numbers.\u003C\u002Fstrong> Track failed refresh rate, average request latency per bank, and consent expiry incidents as ongoing metrics, not one‑off checks.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>If you’re currently pulling data via screen scraping rather than a PSD2 connection, this is also the point to \u003Ca href=\"\u002Fblog\u002Fen\u002Fopen-banking-vs-screen-scraping\" target=\"_blank\" rel=\"noopener\">move to Open Banking\u003C\u002Fa> 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.\u003C\u002Fp>\n\u003Cp>\u003Cstrong>Pro Tip:\u003C\u002Fstrong> \u003Cem>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.\u003C\u002Fem>\u003C\u002Fp>\n\u003Ch2 id=\"permissions-consent-and-the-sca-details-that-catch-people-out\" tabindex=\"-1\">Permissions, consent and the SCA details that catch people out\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cimg loading=\"lazy\" decoding=\"async\" src=\"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789781985692_Selective-open-banking-permission-clusters.jpeg\" alt=\"Selective open banking permission clusters\" \u002F>\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Request the narrowest data cluster that satisfies your use case, not the broadest.\u003C\u002Fli>\n\u003Cli>Treat the 90‑day SCA exemption as the current default, but keep the interval configurable.\u003C\u002Fli>\n\u003Cli>Expect some banks to force earlier reauthentication for risk reasons, independent of the standard window.\u003C\u002Fli>\n\u003Cli>Where volume genuinely justifies it, ask the bank directly about a contractual higher‑frequency or push arrangement.\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"what-actually-works-when-youre-running-this-day-to-day\" tabindex=\"-1\">What actually works when you’re running this day to day\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cimg loading=\"lazy\" decoding=\"async\" src=\"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789782101690_What-actually-works-when-you-re-running-this-day-to-day-overview-diagram.jpeg\" alt=\"What actually works when you're running this day to day — overview diagram\" \u002F>\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cblockquote>\n\u003Cp>\u003Cem>— Gašper Anderle\u003C\u002Fem>\u003C\u002Fp>\n\u003C\u002Fblockquote>\n\u003Ch2 id=\"how-zenith-handles-bank-rules-limitations-for-you\" tabindex=\"-1\">How Zenith handles bank rules limitations for you\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Cp>\u003Cimg loading=\"lazy\" decoding=\"async\" src=\"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1784870754037_zenith-books.jpg\" alt=\"Zenith\" \u002F>\u003C\u002Fp>\n\u003Cp>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 \u003Ca href=\"https:\u002F\u002Fzenith-books.com\u002Fbank-sync\" target=\"_blank\" rel=\"noopener\">Bank Sync product page\u003C\u002Fa> for country coverage, or go straight to \u003Ca href=\"https:\u002F\u002Fzenith-books.com\u002Fpricing\" target=\"_blank\" rel=\"noopener\">current pricing\u003C\u002Fa> to see where it sits against building this yourself.\u003C\u002Fp>\n\u003Ch2 id=\"where-these-rules-actually-come-from\" tabindex=\"-1\">Where these rules actually come from\u003C\u002Fh2>\n\u003Cp>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.\u003C\u002Fp>\n\u003Ch2 id=\"sources\" tabindex=\"-1\">Sources\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"https:\u002F\u002Fstandards.openbanking.org.uk\u002Fcustomer-experience-guidelines\u002Fappendices\u002F90-days-reauthentication-delegated-sca\u002Flatest\u002F\" rel=\"nofollow noopener noreferrer\" target=\"_blank\">90‑Days reauthentication (delegated SCA) — Open Banking Standards\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"faq\" tabindex=\"-1\">FAQ\u003C\u002Fh2>\n\u003Ch3 id=\"how-often-can-i-refresh-bank-data-without-a-live-session\" tabindex=\"-1\">How often can I refresh bank data without a live session?\u003C\u002Fh3>\n\u003Cp>Non‑present access is generally capped at four refreshes in 24 hours under the EBA’s RTS guidance, unless the bank has agreed a higher frequency by contract. Active, in‑session requests aren’t bound by this same cap.\u003C\u002Fp>\n\u003Ch3 id=\"what-triggers-a-forced-reauthentication-before-90-days\" tabindex=\"-1\">What triggers a forced reauthentication before 90 days?\u003C\u002Fh3>\n\u003Cp>Banks can require strong customer authentication earlier than the standard 90‑day window if they detect risk factors on the account or connection. Outside of that, initial SCA covers limited data access for the full 90 days.\u003C\u002Fp>\n\u003Ch3 id=\"do-webhooks-replace-polling-entirely\" tabindex=\"-1\">Do webhooks replace polling entirely?\u003C\u002Fh3>\n\u003Cp>Where a bank supports webhooks or push notifications, they’re the more resilient option and reduce how often you need to poll. Not every bank offers this, so most integrations still need scheduled delta pulls as a fallback.\u003C\u002Fp>\n\u003Ch3 id=\"how-do-i-avoid-hitting-bank-rate-limits\" tabindex=\"-1\">How do I avoid hitting bank rate limits?\u003C\u002Fh3>\n\u003Cp>Read each bank’s rate‑limit headers, respect \u003Ccode>Retry‑After\u003C\u002Fcode> values, and queue retries with exponential backoff instead of retrying immediately. Zenith’s Bank Sync handles this per bank automatically, which is one reason it avoids the manual retry logic most in‑house integrations need to build.\u003C\u002Fp>\n\u003Ch3 id=\"what-does-zeniths-bank-sync-cost-per-account\" tabindex=\"-1\">What does Zenith’s Bank Sync cost per account?\u003C\u002Fh3>\n\u003Cp>Bank Sync is priced at €5 per account per month, with a 5‑minute setup and a 30‑day money‑back guarantee. Full plan pricing, including Starter, Growth, and Business tiers, is listed on the pricing page.\u003C\u002Fp>\n\u003Ch2 id=\"recommended\" tabindex=\"-1\">Recommended\u003C\u002Fh2>\n\u003Cul>\n\u003Cli>\u003Ca href=\"\u002Fblog\u002Fen\u002Fbank-reconciliation-best-practices\" target=\"_blank\" rel=\"noopener\">Bank Reconciliation Best Practices for Finance Teams\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fblog\u002Fen\u002Fmonth-end-close-automation\" target=\"_blank\" rel=\"noopener\">Month End Close Automation: Cut Days Off Your Close\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fblog\u002Fen\u002Fmulti-currency-reconciliation\" target=\"_blank\" rel=\"noopener\">Multi currency reconciliation: a workflow-first playbook\u003C\u002Fa>\u003C\u002Fli>\n\u003Cli>\u003Ca href=\"\u002Fblog\u002Fen\u002Fcash-application-automation\" target=\"_blank\" rel=\"noopener\">Finish Month End in Days: PSD2 Ready Cash Application Automation for EU SMEs\u003C\u002Fa>\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>This article is for general information only and isn’t financial, tax, or legal advice.\u003C\u002Fp>","Practical playbook for SMB finance teams and developers to handle bank rules limitations, avoid four non present refreshes, manage 90 day reauth and stop...","{\"@graph\":[{\"@type\":\"Article\",\"image\":{\"url\":\"https:\u002F\u002Fcsuxjmfbwmkxiegfpljm.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fblog-images\u002Forganization-16364\u002F1789782010033_Analyst-reviewing-an-open-banking-connection.jpeg\",\"@type\":\"ImageObject\",\"caption\":\"Analyst reviewing an open banking connection\"},\"author\":{\"url\":\"https:\u002F\u002Fzenith-books.com\",\"name\":\"Zenith\",\"@type\":\"Organization\"},\"headline\":\"Fix Month End Reconciliation in Weeks: Bank Rules Limitations for SMBs\",\"publisher\":{\"url\":\"https:\u002F\u002Fzenith-books.com\",\"name\":\"Zenith\",\"@type\":\"Organization\"},\"inLanguage\":\"en-GB\",\"description\":\"Practical playbook for SMB finance teams and developers to handle bank rules limitations, avoid four non present refreshes, manage 90 day reauth and stop...\",\"dateModified\":\"2026-09-19T01:41:50.298Z\",\"datePublished\":\"2026-09-19T01:41:50.298Z\"},{\"@type\":\"BreadcrumbList\",\"itemListElement\":[{\"item\":\"https:\u002F\u002Fzenith-books.com\",\"name\":\"Zenith\",\"@type\":\"ListItem\",\"position\":1},{\"item\":\"https:\u002F\u002Fzenith-books.com\u002Fbank-rules-limitations\",\"name\":\"Fix Month End Reconciliation in Weeks: Bank Rules Limitations for SMBs\",\"@type\":\"ListItem\",\"position\":2}]}],\"@context\":\"https:\u002F\u002Fschema.org\"}","{\"@type\":\"FAQPage\",\"@context\":\"https:\u002F\u002Fschema.org\",\"mainEntity\":[{\"name\":\"How often can I refresh bank data without a live session?\",\"@type\":\"Question\",\"acceptedAnswer\":{\"text\":\"Non‑present access is generally capped at four refreshes in 24 hours under the EBA's RTS guidance, unless the bank has agreed a higher frequency by contract. Active, in‑session requests aren't bound by this same cap.\",\"@type\":\"Answer\"}},{\"name\":\"What triggers a forced reauthentication before 90 days?\",\"@type\":\"Question\",\"acceptedAnswer\":{\"text\":\"Banks can require strong customer authentication earlier than the standard 90‑day window if they detect risk factors on the account or connection. Outside of that, initial SCA covers limited data access for the full 90 days.\",\"@type\":\"Answer\"}},{\"name\":\"Do webhooks replace polling entirely?\",\"@type\":\"Question\",\"acceptedAnswer\":{\"text\":\"Where a bank supports webhooks or push notifications, they're the more resilient option and reduce how often you need to poll. Not every bank offers this, so most integrations still need scheduled delta pulls as a fallback.\",\"@type\":\"Answer\"}},{\"name\":\"How do I avoid hitting bank rate limits?\",\"@type\":\"Question\",\"acceptedAnswer\":{\"text\":\"Read each bank's rate‑limit headers, respect Retry‑After values, and queue retries with exponential backoff instead of retrying immediately. Zenith's Bank Sync handles this per bank automatically, which is one reason it avoids the manual retry logic most in‑house integrations need to build.\",\"@type\":\"Answer\"}},{\"name\":\"What does Zenith's Bank Sync cost per account?\",\"@type\":\"Question\",\"acceptedAnswer\":{\"text\":\"Bank Sync is priced at €5 per account per month, with a 5‑minute setup and a 30‑day money‑back guarantee. Full plan pricing, including Starter, Growth, and Business tiers, is listed on the pricing page.\",\"@type\":\"Answer\"}}]}",[],[18,27,35],{"href":19,"slug":20,"locale":5,"title":21,"excerpt":22,"image_url":23,"reading_time":24,"published_at":25,"tag":26},"gr","automated-financial-workflows-for-enterprises","Automated Financial Workflows for Enterprises: 2026 Guide","Automated financial workflows for enterprises: a practical 2026 guide to bank feeds, reconciliation and month-end close automation.","https:\u002F\u002Fcdn.grandranker.com\u002Farticles\u002Fautomated-financial-workflows-for-enterprises-2026-guide-1792111247.jpg",10,"2026-10-16T00:00:00+00:00","how-to",{"href":19,"slug":28,"locale":5,"title":29,"excerpt":30,"image_url":31,"reading_time":32,"published_at":33,"tag":34},"concur-alternative-small-companies","Concur Alternative for Small Companies: 8 Top Picks for 2026","Looking for a Concur alternative for small companies? Compare 8 expense tools on pricing, features and accounting integrations.","https:\u002F\u002Fcdn.grandranker.com\u002Farticles\u002Fconcur-alternative-for-small-companies-8-top-picks-for-2026-1791937371.jpg",15,"2026-10-14T00:00:00+00:00","listicle",{"href":19,"slug":36,"locale":5,"title":37,"excerpt":38,"image_url":39,"reading_time":40,"published_at":41,"tag":26},"how-to-build-financial-ai-agents","How to Build Financial AI Agents: A Step-by-Step Guide","Learn how to build financial AI agents from scratch. Step-by-step guide covering architecture, data integration, tools and security for finance teams.","https:\u002F\u002Fcdn.grandranker.com\u002Farticles\u002Fhow-to-build-financial-ai-agents-a-step-by-step-guide-1791811738.jpg",14,"2026-10-12T00:00:00+00:00"]