Salt Edge review

Salt Edge is a hosted open-banking and open-finance API service, not a client library, command-line tool or self-hosted server. It sits between a financial application and banks or payment providers, giving the application a single integration surface for account data and payment workflows. The vendor says its data aggregation API provides access to thousands of banks globally.

The product spans more than account aggregation. The homepage lists data enrichment, AML transaction monitoring, pay-by-bank, bulk payments, e-commerce payments, open-banking compliance for banks and EMIs, TPP verification and mobile SCA. That makes Salt Edge relevant to fintechs and financial institutions that want to add several open-banking capabilities without building each bank connection independently.

The architectural trade-off is an external dependency: your application relies on Salt Edge and on the bank connections behind it. Before choosing it, map which products you need, which banks and markets matter, and what fallback your application will offer when a connection is unavailable.

The integration surface Salt Edge names is its API. The homepage describes data aggregation through a single API and presents separate services for payments, enrichment, monitoring and compliance. It does not name an API protocol, SDK, programming language, CLI, webhook interface or plugin. Confirm supported protocols, SDKs and implementation examples in the vendor’s developer docs before estimating integration work.

The free developer sandbox provides simulated bank fixtures, so teams can build and exercise an integration without relying on live bank connections. Its stated fetch limits are 2 fetches per second and 7,200 fetches per hour, with 1 automatic fetch per day per end user. Those are sandbox limits; ask Salt Edge for production quotas and behaviour under throttling.

Treat the vendor’s feature list as product scope, not an implementation specification. Confirm authentication, consent handling, error formats, webhook availability, test coverage, bank-specific behaviour and versioning in the docs. Also check how the API surfaces refresh status and connection failures: those details affect retries, user messaging and support load.

The Sandbox / Developer plan is free and includes simulated bank fixtures. It is capped at 2 fetches per second, 7,200 fetches per hour and 1 automatic fetch per day per end user. This is useful for integration work, but it is not a production allowance. The pricing page lists no annual price for the sandbox.

Production pricing is custom. Salt Edge lists Account Information, Payment Initiation and Compliance Solution, with pricing based on end users, payments or SaaS licensing. The vendor does not publish a production starting price, overage schedule or production request limits, so ask for a quote using expected users, payment volume and refresh patterns.

For e-commerce checkout, the listed standard fee is 1% + 10p per transaction. The pricing page also lists 12 months of fee-free invoices for the first 50 sign-ups; confirm eligibility and terms before forecasting savings. Data Enrichment Platform add-ons include transaction categorization, merchant identification and financial insights, but their cost is not published. Budget the production bill only after Salt Edge confirms the applicable model and fees.

Salt Edge presents its services as APIs. The vendor does not publish a software licence or self-hosting option on the product overview, so teams should confirm whether any components are available to run independently before treating this as a deployable dependency. Do not assume the service can be moved into your own infrastructure.

The main lock-in risk is the integration boundary: bank connectivity, data normalization and payments flow through Salt Edge. Replacing it could require a new provider integration, changes to account and transaction models, renewed bank-connection flows and migration of any stored data. The vendor does not publish data-export terms in the product overview. Ask what data can be exported, in which formats, how long it remains available after termination and what happens to active consents.

Keep an internal provider abstraction where practical, and store the financial data your product is permitted to retain. Confirm contractual exit terms and any restrictions on caching or exporting data before production.

Salt Edge’s sandbox limits are specific, but the vendor does not publish production fetch quotas in its pricing details. Ask about rate limits, throttling responses, bank coverage by market, service-level commitments and incident communication before setting application-level guarantees. The homepage lists AML monitoring, compliance and mobile SCA capabilities; evaluate the relevant regulatory and security requirements with the vendor rather than treating feature names as evidence of compliance for your own product.

Reddit reports show why bank connectivity needs monitoring and user-facing fallbacks. In one Chase UK thread, users described a broken connection after a bank interface change; an update relayed from Salt Edge said the team was adapting to the new interface, then encountered a bank-side 500 error. In a separate Banktivity discussion, users reported mixed results: some accounts imported, while others could connect but not refresh or had duplicate transactions.

Build for failed refreshes, delayed data and bank-specific errors. Track connection health, make manual recovery understandable and avoid promising a fixed refresh cadence until Salt Edge confirms production behaviour.