API usage agreement
To the General terms and conditions for the Provision of Payment Services
1. General provisions
- 2FA – Two Factor Authentication used for advanced Account
protection and more secure sign-in.
- Agreement – this API Usage Agreement.
- API – application programming interface which is used as an
additional functionality to integrate the Client’s Account
accessible via the Website into the Client's system.
- API key – encrypted unique user identifier, which is generated
upon the Client’s request, to which particular authorisations for
the Client’s Account usage are assigned.
- API technical specifications – detailed specifications of the
API functionalities, behaviour, expected results, structure and
instructions on how the API should be integrated and used
effectively, which are accessible via
https://bankera.com/api-documentation/ or another link, if
provided by the Institution.
- Client – a legal entity which has engaged into this Agreement.
- Client ID – unique code assigned to the Client, which is
provided via an encrypted file.
- Client secret – authentication token which is used in addition
to the API key in order to authorise the Client with the
authentication server to avoid the Client’s impersonation, which
is provided to the Client via an encrypted file.
- IP address – an IP address that is indicated by the Client and
assigned to it as the main IP address which is used to access the
Client’s Account via the API.
- Other definitions used in the Agreement correspond to those
specified in the General T&C and the Account Agreement, Law on
Payments of the Republic of Lithuania, the Law on Electronic Money
and Electronic Money Institutions of the Republic of Lithuania
and other relevant legal acts.
- The General T&C and the Account Agreement shall form an integral
part of this Agreement. Provisions of the General T&C and the Account
Agreement shall apply in cases both directly stipulated in the
Agreement (e. g. termination of the Agreement) and not directly
stipulated (e. g. applicable law and resolution of disputes)
depending on the context. In the event of contradiction or
discrepancy between the terms and conditions of the Agreement and
the General T&C/the Account Agreement, the terms and conditions of
this Agreement shall prevail, unless the Agreement states otherwise.
2. Subject matter, the set-up and principle of the functionality of the API
- The API functionality is intended for the Client, which wants to
access and use its Account opened in the Institution more easily by
integrating it into the software already used by the Client.
- The Client, which wants to use API functionality, must be verified
- The API integration procedure:
- The Client, which wants to use the API, has to log in to its
Account on the Website and choose section “API” in the Account
- Once the Client receives the message regarding the API, the
Client answers to it by specifying the IP address(-es) which the
Client plans to use for connecting to its Account on the Website
via the API. The Client can select and specify several IP
addresses. The address(-es) may subsequently be edited by the
Client itself by confirming such an action with the 2FA.
- The Client shall implement the API functionality by itself in
accordance with the API technical specifications. The Institution
has a right to make changes to API technical specifications at
any time and in its own discretion by notifying about them in
the aforementioned reference 2 (two) weeks before they enter
into the force.
- In order to duly integrate the API functionality, the Client
- know the Client ID;
- know the API key;
- connect to the API using a valid IP address (Article 2.3.2
of the Agreement).
- The API functionality is provided in the API technical
specifications, which may vary from time to time depending on the
functionalities provided by the Institution. The API functionalities
may vary depending on the group of the Client using the API service.
The Institution does not take any responsibility due to changes to
the API functionality, which may be implemented upon sole discretion
of the Institution. The Client is responsible to follow up all the
changes to and updates of the API technical specifications, and
adapt its systems and processes accordingly. The Client assumes
all risks associated with the alignment of its systems and processes
with changes to and updates of the API technical specifications.
- The Institution may at any time terminate the provision of the API
service, ability to access the API, with or without due notice.
- The Client is informed and duly understands that all payments
initiated through the API are made without further approval by 2FA
and More secure authentication, therefore, the Client accepts and is
duly responsible for all the risks arising therefrom.
- The API functionality is provided to the Client free of charge.
- The Institution shall not be liable for any damages arising from
the access to or use of the API, including, but not limited to, the
management of the respective Account through the API, following
instructions and/or codes provided in the API technical specifications.
- The Institution is not liable for any losses (both direct and
indirect) that the Client may incur due to any downtime of the API
or any functionality of it, inability to access or use the API or
relevant services via the API according to the API technical
specifications (including, but not limited to, the cases mentioned
in Article 2.5 of the Agreement).
3. Parties’ obligations
- The Client undertakes to:
- implement the API in accordance with the instructions presented
in Article 2.3 of the Agreement and continue to use the API
functionality in a fair and orderly manner;
- use only valid IP address to connect to the API;
- not to abuse the functionality of the API;
- ensure the security and integrity of the Account and the
computer or interface accessible through the API;
- be responsible for all actions performed through the API
functionality in the Client’s Account, including, but not limited
to, initiation of the payments, logins, usage of the Account,
processing of information contained in the Account;
- be responsible for protecting the Client’s used technical
measures, software, data and other systems against viruses,
malware and other internet security risks;
- ensure that by using the API functionality the Client will
not expose the Institution to the malicious software or security
risks such as malware, trojans, viruses and any other material
which is malicious or technologically harmful either to the API,
the Institution or other clients of the Institution;
- periodically, at least once a month, check the API technical
specifications in order to be aware of the planning adjustments,
and, if there are any, make the necessary adjustments without
undue delay in the Client’s part of the integration of the API;
- to comply with the security requirements listed in Article 4
of the Agreement.
- The Institution undertakes to:
10. maintain the functionality of the API, correct and make the
API updates and changes necessary for the proper functioning of
11. ensure the provision of main services as provided for in the
General T&C, the Account Agreement and other agreements signed by
the Parties when the services are provided to the Client using
4. Security measures
- Each Client, which decides to integrate the API, obliges to duly
comply with the minimum organisational and technical data security
requirements set herein. These security requirements are designed
in order to safeguard data that is processed via use of the API
against corruption, loss or access from unauthorised third party.
- Organisational security measures:
- Security policy and procedures for the protection of personal
- The Client should document a separate dedicated security
policy with regard to the processing of personal data. The
policy should be approved by management and communicated to
all employees and relevant external parties.
- The security policy should be reviewed and revised on an
- Roles and responsibilities
- Roles and responsibilities related to the processing of
personal data should be clearly defined.
- Clear appointment of persons in charge of specific security
tasks should be performed.
- Access control policy
- Specific access control rights should be allocated to each
role (involved in the processing of personal data) following
the “need to know” principle.
- An access control policy should be detailed and documented.
The Client should determine in this document the appropriate
access control rules, access rights and restrictions for
specific user roles towards the processes and procedures
related to personal data.
- Access rights should be reviewed on annual basis and
revoked as soon as they are no longer needed.
- (For High-risk cases) Roles with excessive access
rights should be clearly defined and assigned to limited
specific members of staff.
- Asset management
- The Client should have a register of the IT resources used
for the processing of personal data (hardware, software, and
network). The register could include at least the following
information: IT resource, type (e.g. server, workstation),
location (physical or electronic). A specific person should
be assigned the task of maintaining and updating the register.
- Roles having access to certain resources should be defined
- IT resources should be reviewed and updated on annual basis.
- Change management
- To ensure that all changes are recorded, tested, evaluated,
validated, implemented and verified, the Client should
establish and implement change management process. The Client
must assess whether changes in the current operating
environment affect existing security measures or require
additional risk mitigation measures. Such changes must be
implemented in accordance with the Client’s documented
change management process.
- Software development should be performed in a special
environment, which is not connected to the IT system used
for the processing of personal data. When testing is needed,
dummy data should be used (not real data). In cases where
this is not possible, specific procedures should be in place
for the protection of personal data used in testing.
- Data processors
- Formal guidelines and procedures covering the processing
of personal data by data processors (contractors/outsourcing)
should be defined, documented and agreed between the data
controller and the data processor prior to the commencement
of the processing activities. These guidelines and procedures
should mandatorily establish the same level of personal data
security as mandated in the organisation’s security policy.
- Upon finding out of a personal data breach, the data
processor shall notify the controller without undue delay.
- Formal requirements and obligations should be formally
agreed between the data controller and the data processor.
The data processor should provide sufficient documented
evidence of compliance.
- The data controller’s organisation should regularly audit
the compliance of the data processor to the agreed level of
requirements and obligations.
- (For High-risk cases) The employees of the data
processor who are processing personal data should be subject
to specific documented confidentiality/non-disclosure
- Incident handling / Personal data breaches
- An incident response plan with detailed procedures should
be defined to ensure effective and orderly response to
incidents pertaining personal data.
- Personal data breaches should be reported immediately to
the management. Notification procedures for the reporting of
the breaches to competent authorities and data subjects
should be in place following Articles 33 and 34 of GDPR.
- The incidents’ response plan should be documented, including
a list of possible mitigation actions and clear assignment
- (For High-risk cases) Incidents and personal data
breaches should be recorded along with details regarding the
event and subsequent mitigation actions performed.
- Business continuity
- The organisation should establish the main procedures and
controls to be followed in order to ensure the required level
of continuity and availability of the IT system processing
personal data (in the event of an incident/personal data
- A business continuity plan should be detailed and
documented (following the general security policy). It should
include clear actions and assignment of roles.
- Business continuity plans should be tested and updated
annually, based on test results from collected data on
threats and experience from previous events, as well as
changed recovery objectives and/or changed operational
functions, support processes and information resources.
- Confidentiality of personnel
- The Client should ensure that all employees understand
their responsibilities and obligations related to the
processing of personal data. Roles and responsibilities
should be clearly communicated during the pre-employment
and/or induction process.
- Prior to up taking their duties, employees should be asked
to review and agree on the security policy of the
organisation and sign respective confidentiality/non-disclosure
- (For High-risk cases) Employees involved in high-risk
processing of personal data should be bound to specific
confidentiality clauses (under their employment contract or
other legal act).
- The Client should ensure that all of its employees are
adequately informed about the security controls of the IT
system that relate to their everyday work. Employees involved
in the processing of personal data should also be properly
informed about relevant data protection requirements and
legal obligations through regular awareness campaigns.
- The Client should have structured and regular training
programs for staff, including specific programs for the
induction (to data protection matters) of newcomers.
- The Client should ensure that all of its employees receive
training at least once a year.
- Technical security measures:
- Access control and authentication
- The use of common user accounts should be avoided. In cases
where this is necessary, it should be ensured that all users
of the common account have the same roles and responsibilities.
- An authentication mechanism should be in place, allowing
access to the IT system (based on the access control policy
and system). As a minimum a username/password combination
should be used. Passwords should respect a certain
(configurable) level of complexity.
- A specific password policy should be defined and documented.
The policy should include at least password length,
complexity, validity period, as well as number of acceptable
unsuccessful login attempts.
- User passwords must be stored in a “hashed” form.
- Logging and monitoring
- Log files should be activated for each system/application
used for the processing of personal data. They should include
all types of access to data (view, modification, deletion).
- Log files should be timestamped and adequately protected
against tampering and unauthorised access. Clocks should be
synchronised to a single reference time source.
- Actions of the system administrators and system operators,
including addition/deletion/change of user rights should be
- There should be no possibility of deletion or modification
of log files content. Access to the log files should also be
logged in addition to monitoring for detecting unusual
- A monitoring system should process the log files and
produce reports on the status of the system and notify for
- Server / Database security
- Servers should be configured in accordance with documented
- Server images should be reviewed, tested and kept up to
date (i.e. with recent patches and changes to
- Servers should be configured to protect against attacks
by: disabling unnecessary or insecure user accounts, changing
important security-related parameters from their default
settings, restricting physical access to a limited number
of authorised individuals, maintaining up-to-date malware
protection software, monitoring, and by reviewing them on
a regular basis.
- Database and applications servers should only process
the personal data that are actually needed to process in
order to achieve its processing purposes.
- (For High-risk cases) Encryption solutions should be
considered on specific files or records through software or
- (For High-risk cases) Encrypting storage drives should
- Workstation security
- Users should not be able to deactivate or bypass security
- Users should not have privileges to install or deactivate
unauthorised software applications.
- The system should have session time-outs when the user has
not been active for a certain time period.
- Critical security updates released by the operating system
developer should be installed regularly.
- (For High-risk cases) It should not be allowed to
transfer personal data from workstations to external storage
devices (e.g. USB, DVD, external hard drives).
- (For High-risk cases) Full disk software encryption should
be enabled on the workstation operating system drives.
- Network / Communication security
- Whenever access is performed through the Internet,
communication should be encrypted through cryptographic
- Wireless access to the IT system should be protected by
- Remote access to the IT system should in general be
avoided. In cases where this is absolutely necessary, it
should be performed only under the control and monitoring
of a specific person from the Client (e.g. IT
administrator/security officer) through pre-defined devices.
- The network of the information system should be segregated
from the other networks of the data controller.
- Backup and data restore procedures should be defined,
documented and clearly linked to roles and responsibilities.
- Backups should be given an appropriate level of physical
and environmental protection consistent with the standards
applied on the originating data.
- Execution of backups should be monitored to ensure
- Backup media should be regularly tested to ensure that
they can be relied upon for emergency use.
- Copies of the backup should be securely stored in
- In case a third-party service for backup storage is used,
the copy must be encrypted before being transmitted from the
- Mobile / Portable devices
- Mobile and portable device management procedures should
be defined and documented establishing clear rules for their
- Mobile devices that are allowed to access the information
system should be pre-registered and pre-authorised.
- Mobile devices should be subject to the same levels of
access control procedures (to the data processing system) as
other terminal equipment.
- Personal data stored at the mobile device (as part of the
organisation’s data processing operation) should be encrypted.
- Application lifecycle security
- During the development lifecycle best practices, state of
the art and well acknowledged secure development practices,
frameworks or standards should be followed.
- Specific security requirements should be defined during
the early stages of the development lifecycle.
- Specific technologies and techniques designed for
supporting privacy and data protection (also referred to as
Privacy Enhancing Technologies (PETs)) should be adopted in
analogy to the security requirements.
- Secure coding standards and practices should be followed.
- During the development, testing and validation against the
implementation of the initial security requirements should
- Vulnerability assessment, application and infrastructure
penetration testing should be performed prior to the
operational adoption. The application shall not be adopted,
unless the required level of security is achieved.
- Periodic penetration testing should be carried out.
- Information about technical vulnerabilities of information
systems being used should be obtained.
- Software patches should be tested and evaluated before
they are installed in an operational environment.
- Data deletion / disposal
- Multiple passes of software-based overwriting should be
performed on all media prior to their disposal. In cases where
this is not possible (CD’s, DVD’s, etc.), physical destruction
should be performed.
- Shredding of paper and portable media used to store
personal data shall be carried out.
- (For High-risk cases) If a third party’s services are
used to securely dispose of media or paper-based records, a
service agreement should be in place and a record of
destruction of records should be produced as appropriate.
It should be considered that the process takes place at the
premises of the data controller (and avoid off-site transfer
of personal data).
- Physical security
- The physical perimeter of the IT system infrastructure
should not be accessible by non-authorised personnel.
Physical barriers should, where applicable, be built to
prevent unauthorised physical access.
- Clear identification, through appropriate means, e.g. ID
Badges, for all personnel and visitors accessing the
premises of the organisation should be established as
- Secure zones should be defined and be protected by
appropriate entry controls. A physical logbook or electronic
audit trail of all access should be securely maintained and
- Intruder detection systems should be installed in all
- Vacant secure areas should be physically locked and
- An automatic fire suppression system, closed control
dedicated air conditioning system and uninterruptible power
supply (UPS) should be implemented at the server room.
- The Institution may inspect the Client and ask to provide proof
that the aforementioned security requirements are being met within
the Client’s organisation. If the Institution finds that the Client
does not comply with any of security requirements, the legal measures
regulated in Clause 6 of this Agreement, among other measures, may
be applied to the Client.
5. Compromise of authorization elements
- In the event the Client losses the confidentiality of any of the
authorisation measures indicated in Article 2 of the Agreement,
which are used by the Client in order to access and use its Account
via the API, or there is a serious threat or suspicion that such
authorisation elements have become known to unauthorised third party
(f. e., there is a hack into the Client’s system), the Client must
notify the Institution immediately.
- Once the Institution receives the Client’s notification, the
Institution deactivates the API key and (or) removes the respective
IP address (indicated in Article 2.3.2 of the Agreement), which was
primary assigned to the Client, from the approved IP list, so that
it would be impossible to further access the Account via the API.
Used API keys are never used again. In case the Client requires,
the Institution could temporally or permanently block the Client’s
Account as well.
- The Institution has a right to block the API key and/or the
Client's Account on its own initiative if it has a reason to suspect
that the API key used by the Client is compromised. In such cases
the Institution shall immediately, but no later than within 3 (three)
Business Days, inform the Client about the blocking of the API key
and/or the Client's Account, and the Client, in turn, undertakes
immediately, but no later than within 3 (three) Business Days, to
provide information required by the Institution, which is needed to
clarify the suspicions that have arisen. Until the Client provides
information required by the Institution, the creation of a new API
key is suspended. In such cases the Institution shall not be liable
for any losses (both direct and indirect) of the Client that it may
incur as a result of the blocking of the API key and/or the
Client’s Account. If the Client fails to provide information
required by the Institution within the prescribed term, the
Institution shall have a right to terminate this Agreement
immediately without any notice.
- The Institution takes all necessary measures it deems appropriate
and useful to prevent any possible consequences arising from
compromise of the Client’s authorisation elements, however, the Client
is solely responsible for ensuring the confidentiality and security
of its used authorisation elements, access to API, software, internet
connection and any other technical measures the Client uses. The
Client is solely responsible for all consequences arising out of
such loss of confidentiality and security of authorisation elements.
- The Client takes all the risk, responsibility and obligation to
cover all possible damages if it does not fulfil its obligations set
out in Clause 3.1 of this Agreement, and/or does not follow security
measures stated in Article 4 of this Agreement. The Client is fully
responsible towards the Institution and any other third party, if
any of its data is leaked or compromised or any other deficiency
occurred. In such cases Institution takes no responsibility towards
the Client or any third parties, if there is damage caused sue to
data leak, compromised services or any other deficiency.
- In cases where the Client fails to fulfil its obligations under
this Agreement, including the obligation to comply with and
implement any of the security measures set out in Article 4 of the
Agreement, the Client shall be obliged to bear all losses of the
Institution arising from the Client's breach of this Agreement and
to pay a fine of 50 000 EUR (fifty thousand euros) to the
Institution (in each case when breach of the Agreement is found).
Besides, in such cases the Institution may cease the provision of
the API functionality, terminate this Agreement.
- This Agreement could be terminated on any grounds specified in
the General T&C or in the Account Agreement.
- The Institution without any prior notice may suspend or terminate
the Client’s access and use of the API, as well as terminate this
Agreement in case there are obvious grounds to believe that the
Client has breached terms and conditions of this Agreement.