Introduction to Open Banking Data

Feezback is Israel's open banking aggregator: one integration and one API instead of a separate connection to every bank and credit card company. On the data side, Feezback offers two flows built on the same consent mechanism:

• Data Aggregation and Enrichment
  Standardized and enriched transactions and balances data from any account type(cash, card, loan, savings, securities)

• Insight Report
  Selivered as a webpage view or as JSON.

Feezback pulls data exclusively through each institution's official open banking API. It never uses a customer's bank username or password, and never scrapes bank websites or apps.

General Process

1. Request data access consent from your customers*.
2. Get standardized and enriched transactions and balances data from any account, supporting: Checking, Card, Loan & Credit , Savings, Securities.
3. Get aggregated insights and credit score based on data from multiple accounts
4. Get updates on financial events detected on connected accounts.

How it works?

Access always starts with the customer's explicit, informed consent:

1. Your backend creates a signed consent request specifying which data and account types you're asking for.
2. The customer is sent to Feezback's hosted consent screen, where they see exactly what is being requested and approve (or decline) it.
3. The user is redirected to approve the request on the bank app/website.
4. Feezback notifies your backend once the consent is granted, and again once the first data pull completes.
5. The customer can revoke consent at any time; your backend is notified of the change and access stops immediately.

How consent is managed per person

Consent in Feezback is tracked per person, not per bank connection. Feezback identifies that person by the userId you assign them (built from your own sub value, as {sub}@{tpp_id}) — and a single userId can hold several independent consents at once: one to their bank account, another to a different bank, another to a credit card company, another to a pension fund or insurer, and so on.

Each of those consents is still its own, separate thing:

• Granted separately — every institution the person connects requires its own consent flow; connecting a second bank doesn't reuse or extend the first consent.
• Managed separately — you can look up or terminate one specific consent (GET/DELETE /tpp/v1/users/USERID/consents/{consentId}) without touching the person's other connections.
• But aggregated together at the person level — call the person-level endpoints instead of a single-consent one (e.g. GET /tpp/v1/users/USERID/accounts rather than GET /tpp/v1/users/USERID/consents/{consentId}/accounts), and Feezback returns data from every valid consent that person holds, combined. The same pattern applies to cards, loans, savings, and securities.

In practice: if the same person connects their checking account at one bank, a credit card at another institution, and their pension fund, Feezback presents all three back to you as a single, unified financial profile for that person — while still letting either of you disconnect any one of those connections independently, without affecting the rest.

What data you get

Access is scoped by three choices made at consent time:

What you can do with it

Core, out-of-the-box uses of this data include:

• Financial dashboards for your users — either build your own on the raw data, or use Feezback's ready-made VIEW dashboard.
• Credit underwriting and risk assesment — Feezback's Credit Score and financial-event signals (bounced payments, bank warnings, loan payment delays) are computed directly from consented data, so no separate data-sharing agreement is needed once a data consent is in place.
• Combining data with payments — pairing a data consent with Feezback's payment-initiation service lets you both see a customer's financial picture and act on it (e.g., initiate a transfer) inside the same product experience.

Regulatory Basis

How Feezback is regulated and licensed to operate

Feezback operates under two authorizations, both granted and supervised by the Israel Securities Authority (ISA):

Feezback does not hold customer funds, operate a payment account, issue payment instruments, or perform clearing — its data license only permits collecting and presenting data by consent, nothing beyond that.

Who can get financial data in Israel, according to the law

The Financial Information Service Law sets up a three-party structure, and — importantly — the law does not treat every information-service provider the same way. It splits eligibility into two tracks:

• Full ISA license (Section 2(a) + Section 4(a)) — the default rule: any entity that is not one of the specific bodies listed below may not provide a financial information service unless it holds a license issued directly by the Israel Securities Authority. Getting this license requires meeting conditions such as being an Israeli-incorporated company managed in Israel, having adequate technological safeguards, a viable business plan, minimum equity, and no disqualifying circumstances (e.g. insolvency). This is Feezback's track — Feezback is not a bank, insurer, or other pre-existing regulated financial entity, so it obtained a full ISA license rather than a lighter approval.
• Lighter "approval," not a new license (Section 2(b) + Section 13(b)) — entities that are already licensed/regulated elsewhere for financial activity — banks, payment service providers, ancillary corporations, institutional bodies (insurers, pension and provident fund managers), licensed credit or deposit providers, credit-intermediation system operators, and portfolio managers — don't need to apply for a brand-new ISA license to also offer a financial information service. They only need an approval from their own existing regulator (e.g. a bank gets this approval from the Bank of Israel, not the ISA), and the only substantive condition carried over is the technological-safeguards requirement from Section 4(a)(3).
• A narrow exemption (Section 3(a)) exists for a financial entity that receives data from a licensed information service provider for a specific, defined purpose — that receiving entity doesn't need its own license or approval for that particular use.
• Customers remain the owners of their own data throughout, and their explicit, revocable consent is what authorizes any of this data movement — regardless of which track the provider is on.

In short: an entity must either hold this full ISA license, or already be one of the specific regulated entity types that qualifies for the lighter, self-regulator-issued approval — there is no third path to lawfully collecting a customer's financial data in Israel.

Feezback's data saving and deletion protocol

The data Feezback holds belongs to the customer, not to Feezback — this is a standing duty under the law, alongside compliance with the ISA's information security directive.

In practice, retention is tied to the consent lifecycle:

• While a consent is valid, Feezback refreshes and stores the data needed to serve it.
• When a consent is revoked by the customer, or terminated, Feezback's systems trigger a deletion process for the corresponding data.
• Deletion status can be tracked (deletion reason is recorded as either an expiration-driven deletion or a consent-driven deletion), and a customer's data can also be deleted from Feezback's systems on request, subject to any applicable retention obligations.