Enable Banking

Enable Banking is a free third-party provider that allows you to connect European bank accounts to Sure using PSD2 open banking standards. It supports thousands of banks across the EU. See Transaction history and import limits for initial sync defaults, history limits, and options for older transactions.

​

How it works

Enable Banking uses the PSD2 open banking framework to securely access your bank data:

1. Select your bank from the list of supported institutions
2. Authorize Sure to access your account through your bank’s authentication flow
3. Sure syncs your account balances and transactions
4. Data is refreshed periodically to keep your information current

All authentication happens directly with your bank. Enable Banking and Sure never see your banking credentials. The authorization flow is tied to your browser session. Sure generates a unique, random state value for each authorization attempt and stores it in your session. When your bank redirects back to Sure, the callback is matched against that stored state before proceeding. This means the authorization must complete in the same browser where you started it.

​

Supported regions

Enable Banking supports banks across the European Union and EEA countries. You can query available banks by country code (e.g., “GB”, “DE”, “FR”).

​

Setting up Enable Banking

To connect your European bank accounts:

1. Obtain an Enable Banking application ID and client certificate from Enable Banking
2. Register Sure’s callback URL in your Enable Banking application settings
3. In Enable Banking, link your bank account to the application
4. In Sure, configure your Enable Banking credentials
5. Select your country and bank from the available options
6. Complete the authorization flow with your bank
7. Sure creates a session and begins syncing your accounts

If you want to connect another bank, or connect the same bank with a different login, use Add Connection after your first Enable Banking connection is working. Sure stores each Enable Banking connection separately, so you can sync, reconnect, or remove them independently. Make sure to link the bank account first in the Enable Banking portal, and then create the bank connection in Sure.

​

Updating credentials

When you update an existing Enable Banking connection, the Application ID and Client Certificate fields are empty. Leave either field blank to keep the stored value. Enter a new value only when you need to replace a credential. For existing provider configurations, both credential fields are disabled while any Enable Banking connection in your family has a stored session. This applies across configurations, rather than depending only on the status of the connection being edited. Remove the connections with stored sessions before changing credentials.

​

Using one provider config across different countries

You do not need to create a separate Enable Banking provider configuration for each country. Use one shared Enable Banking configuration with your application ID and client certificate, then use Add Connection for each additional bank you want to link. When adding each bank connection:

1. Start from Settings > Bank sync > Enable Banking
2. Choose the country in Country Code list
3. Save the configuration with selected country
4. Click Add Connection
5. Select the bank in that country
6. Complete authorization

Example: you can keep one Enable Banking provider config in Sure, then add one connection for a Spanish bank and another connection for a German bank using the same credentials.

​

Features

​

Account access

• Account details: View account information including IBAN and account type
• Balance information: Balance data fetched from your bank using a priority order that prefers reconciled booked figures
• Transaction history: Import historical transactions with date range filtering
• Multiple accounts: Connect multiple accounts from different banks
• Duplicate detection: Automatic deduplication of transactions with different entry reference IDs

​

Session management

Enable Banking uses sessions to maintain access to your accounts:

• Session validity depends on your bank’s maximum consent period, up to 180 days
• You can revoke access at any time by deleting the session
• Sessions automatically refresh to keep data current

Sure requests the longest consent window your bank advertises (capped at 180 days by default), so reauthorization happens as infrequently as possible. If your bank rejects the requested duration, Sure automatically retries with progressively shorter windows (90, 45, and 30 days) until the bank accepts one. Set the ENABLE_BANKING_CONSENT_DAYS environment variable to a whole number of days to override the 180-day ceiling. Only integer values are accepted; non-integer strings are ignored and the default is used.

​

Transaction period retries

Some banks reject a sync request when the requested date range is outside the window they allow. Sure automatically retries with a shorter window when this happens. N26 reports this condition with {"code": "PERIOD_INVALID", ...} rather than the more common WRONG_TRANSACTIONS_PERIOD error shape. Sure recognizes both forms and applies the same retry ladder, so N26 syncs recover automatically instead of failing outright.

​

Transaction syncing

When syncing transactions, Sure imports both booked and pending transactions:

• Booked transactions: Confirmed transactions from your bank
• Pending transactions: Transactions that have not yet settled (visible for 1–3 days before they become booked)
• When a pending transaction settles, the pending entry is automatically replaced by the booked version
• You can filter synced transactions by date range
• Large transaction sets are paginated automatically

​

Pending transactions

By default, Sure imports both booked and pending (uncleared) transactions from Enable Banking. Pending transactions are automatically reconciled once they post as booked. You can disable pending transaction imports in your sync settings by toggling “Include pending transactions” off. When disabled, only booked transactions are imported, and any previously stored pending transactions are removed during the next sync.

​

Card authorization holds

Some banks (ASPSPs) return unfinalized card authorization holds with a BOOK status while omitting the transaction_id, entry_reference, and creditor information. The remittance field contains a masked card descriptor instead of a merchant name (for example 474836xxxxxx6879 003015315475), and the credit/debit indicator may be set to CRDT even though the hold is an outgoing expense. Sure detects these holds by checking for a masked card descriptor in the remittance field when the transaction lacks identifying fields. Detected holds are:

• Named Card Authorization Hold
• Imported as pending expenses (no merchant is created)
• Corrected to a positive outgoing amount when the bank erroneously reports them as credit

When pending transactions are disabled, unidentified card holds are filtered out and not imported.

​

Balance selection

When Enable Banking returns multiple balance types for an account, Sure picks the most reliable figure using a fixed priority order that prefers reconciled booked balances over available or expected ones:

1. CLBD / closingBooked — closing booked balance
2. ITBD / interimBooked — interim booked balance
3. OPBD / openingBooked — opening booked balance (start of current period)
4. PRCD / previouslyClosedBooked — previously closed booked balance (end of last period)
5. XPCD / expected — expected balance
6. CLAV / closingAvailable — closing available balance
7. ITAV / interimAvailable — interim available balance

Available balances are last because some banks include an arranged overdraft facility in the available figure, which would overstate actual cash. OPBD and PRCD are period-boundary snapshots rather than live figures, so they may be up to a day old. To guard against this, Sure checks the optional reference_date field on each balance. If the same response contains a newer XPCD, CLAV, or ITAV balance with a strictly later reference_date, the fresher balance wins instead of the period-boundary one. When reference_date is absent on either side, the priority order applies unchanged. If none of the recognised types are present, Sure falls back to the first balance the API returns.

​

Credit cards with “Balance is available credit”

When a credit card account has the Balance is available credit setting enabled, Sure uses a different priority order that prefers available balance types first:

1. CLAV / closingAvailable — closing available balance
2. ITAV / interimAvailable — interim available balance
3. Then the same booked order as above (CLBD, ITBD, OPBD, PRCD, XPCD)

This is needed because some banks (for example mBank PL) report the credit limit as the booked balance (ITBD) and the actual available credit as ITAV. Without this adjustment, Sure would treat the credit limit as available credit, producing zero calculated debt. XPCD (expected) stays after the booked types in this order because it is a projected booked balance, not an available credit figure. This available-first priority only applies when the provider account is linked to a credit card account in Sure. If the account is later relinked to a different account type, Sure falls back to the standard booked-first order even if the “Balance is available credit” flag is still set.

​

Multi-currency accounts

Some wallets and payment services (such as PayPal) report multiple balances under the same balance type — one per currency — in a single response. Without special handling, the last entry would win, causing the account to display the wrong currency and an empty balance. When Sure detects a multi-currency response, it keeps only the balances in the account’s reported currency:

• Sure reads the currency from the raw account snapshot, not the stored column, to avoid using a value that a previous faulty sync may have set incorrectly.
• If the snapshot currency is not present in the response (for example, PayPal reports XXX for its wallet), Sure falls back to the first recognized currency returned.
• Balances in other currencies are not discarded silently. If any non-selected currency carries a non-zero amount, Sure logs the details to Settings > Debug under the provider_sync category so support can investigate if needed.

Single-currency accounts are not affected by this logic.

​

Account type mapping

Sure automatically maps your bank’s account types to the appropriate Sure account type:

• Checking accounts (CACC, TRAN, SALA, and others) map to depository accounts
• Savings accounts (SVGS, MOMA) map to depository savings accounts
• Credit cards (CARD, CRCD) map to credit card accounts
• Loans and mortgages (LOAN, MORT) map to loan accounts

​

Automatic transfer detection

When syncing transactions from Enable Banking, Sure automatically detects certain transfer types based on the destination account:

• Loan payments: Transactions to loan accounts are automatically classified as loan payment transfers
• Credit card payments: Transactions to credit card accounts are automatically classified as credit card payment transfers

See transfers for more details on how transfer types affect budgets.

​

Transaction name cleanup

For banks that return remittance information as a multi-line array (common with Austrian and German banks such as BankDirekt/Raiffeisen), Sure automatically selects the most descriptive line as the transaction name. Technical terminal descriptor lines — such as POS 45,13 AT D6 31.07. 10:27 — are skipped in favour of the actual merchant name. Sure strips payment wallet prefixes (Apple Pay, Google Pay, Samsung Pay) from remittance lines before reading the payee name. Some banks prepend the wallet used to make a payment — for example, Apple Pay: Coffee Shop Name — onto the transaction descriptor. Stripping the wallet prefix ensures the real merchant name is used for matching and display, so a purchase from Apple’s own store does not cause all subsequent wallet-paid transactions to be labelled as Apple purchases. Sure also strips known small-merchant payment-processor prefixes (SumUp, Square, iZettle, PayPal) from the selected line, and matches the transaction against your family’s known merchants for a cleaner display name.

​

Duplicate transaction handling

Enable Banking includes robust content-based deduplication to prevent API-level duplicate transactions:

• The API sometimes returns the same logical transaction multiple times with different entry_reference IDs
• Sure uses a composite key based on transaction content, including transaction_id when present, plus date, amount, currency, creditor and debtor information, remittance information, status, and credit/debit indicator
• When multiple transactions have identical content, only the first occurrence is kept
• The credit_debit_indicator helps distinguish between payments and refunds of the same amount on the same day

This keeps your transaction history clean and accurate even when the API returns duplicate data.

​

ID-less transaction handling

Some banks (ASPSPs) omit both transaction_id and entry_reference from their responses, which are both optional under PSD2. For these transactions, Sure generates a deterministic ID based on date, amount, currency, direction, creditor, debtor, and remittance information. When the bank later assigns a real identifier to one of these transactions — for example, once a statement closes — Sure re-keys the stored row to the new identifier rather than importing a second entry. This preserves any category, merchant, or transfer link already attached to the original row. This re-keying only applies to booked (settled) transactions on both sides. Pending transactions are excluded from the re-keying pool and from the candidate set that receives claims, so Enable Banking’s own pending-to-booked reconciliation handles the settlement transition independently without the two mechanisms conflicting. Transactions that already carry a provider ID are not affected by this logic.

​

Supported account types

Enable Banking supports both personal and business accounts:

• Personal accounts: Standard consumer bank accounts (default)
• Business accounts: Business banking accounts

When connecting a bank, Sure validates the selected account type against the types your bank supports. If your bank only supports one type, it is selected automatically.

​

API reference

For technical details about the Enable Banking API, see the official documentation.

​

Troubleshooting

​

Authorization callback fails with “Connection not found”

Sure could not resolve a pending authorization for your current browser session and family. The returned state may not match a pending attempt, or the associated connection may no longer be available. It can happen if you:

• Opened the bank’s authorization page in a different browser or profile than the one where you started the flow
• Completed the bank’s authorization after your Sure session expired
• Navigated away from Sure and your session was cleared

Start the authorization again from Settings > Bank sync > Enable Banking and complete the bank’s approval without switching browsers or letting your session time out.

​

N26 and PERIOD_INVALID errors

N26 (and some other ASPSPs via Enable Banking) rejects out-of-range transaction date windows with a PERIOD_INVALID error rather than the more common WRONG_TRANSACTIONS_PERIOD shape. Sure recognizes both error shapes and automatically retries the sync with a shorter date window, so you should not need to take any action if a sync fails with this error.

​

Bank rejects the session mid-sync

Some banks reject an Enable Banking session with a 401 or 404 during a sync even though the session has not yet expired by its recorded expiry date. When this happens, Sure marks the connection as requiring re-authorization and finishes the sync cleanly — the connection card shows a Reconnect prompt instead of a green “Connected” status. Click Reconnect and complete the bank authorization flow again to restore syncing.

​

Syncs keep failing without a reconnect prompt

Enable Banking sometimes rejects individual account balance or transaction requests with a 401 “Invalid credentials or expired JWT” while the session-level check still reports the session as valid. Because only a session-level failure flips the connection to requires_update, the connection card stays green and no reconnect prompt appears automatically. Syncs can fail for the affected accounts without requesting reauthorization; these failures can still appear as sync errors. To reconnect manually, an admin can open the action menu on the connection card and choose Reconnect. This option is always available as long as the connection is not already showing a reconnect prompt. Clicking it routes through the same reauthorization flow as a normal reconnect, so you do not need to disconnect and re-add the bank.

​

Limitations

• Only supports banks in EU/EEA countries
• Requires PSD2-compliant banks
• Session validity depends on your bank’s consent limits (up to 180 days)
• Banks that use decoupled authentication (separate device approval) are not supported
• Subject to Enable Banking API rate limits
• Some banks may have additional authentication requirements