Open Banking

An application programming interface, or API, allows software systems to request defined services from one another. Finnotech’s own company profile places APIs at the center of its Iranian open-banking offering. It describes an ecosystem involving service providers, businesses, and developers, and lists banking and payment alongside capital-market, insurance, municipal, and governance services. This is evidence of the company’s stated scope, rather than independent verification of every listed capability. s1

That breadth helps explain why “open banking” can appear beside the wider language of open innovation. Finnotech describes an ambition to connect multiple service domains, not simply reproduce a bank’s consumer application. Its profile supports the existence of this provider model, but does not establish a universal Iranian technical standard, mandatory bank participation, or a legal right to obtain account data. s1

Vandar’s introductory documentation distinguishes credentials for different products. It describes API keys for gateway integration and valid tokens for other APIs, while warning that availability can depend on a business user’s access level. The published services use REST interfaces, a common style of web API. s2

Its authentication guide explains how a business owner or manager obtains an initial access token and refresh token through the dashboard. The guide distinguishes the token used to call services from the refresh token used to renew access. These credentials authenticate the business’s software relationship with the platform; they should not be read as evidence that every customer has authorized access to a bank account. s3

The distinction is visible in the documentation itself: business authentication has its own instructions, while account-related authorization appears in a separate payment workflow. This separation is central to understanding the service, because an application’s ability to make an API request and a customer’s permission for a financial action are different questions. s2s3

Vandar’s automatic-payment documentation describes direct debit as withdrawal from a bank account with the payer’s authorization. Its published process creates an authorization request, directs the customer to a bank page, and requires confirmation of the resulting authorization. The request includes limits on withdrawal amount and frequency, together with an expiry date. s4

Bank coverage and operational availability are separate concerns. The documentation exposes checks for whether a bank supports direct debit and whether that service is healthy at the time of use. A bank appearing in a documentation example therefore does not prove uninterrupted availability. s4

This example shows a permission-based account-payment process. It does not establish that the same platform provides unrestricted transaction histories, identical permissions across banks, or the full range of services associated with open banking elsewhere. A broader assessment of Iran requires current bank documentation and regulatory evidence in addition to these provider accounts.

A published account-payment authorization workflow

The arrows describe the authorization process in Vandar's published documentation. They do not represent universal bank coverage, regulatory supervision, or proof of a successful debit.