API usage agreement

1. 1. General provisions

   1. Definitions:
      1. 2FA – Two Factor Authentication used for advanced Account protection and more secure sign-in.
      2. Agreement – this API Usage Agreement.
      3. 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.
      4. 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.
      5. 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.
      6. Client – a legal entity which has engaged into this Agreement.
      7. Client ID – unique code assigned to the Client, which is provided via an encrypted file.
      8. 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.
      9. 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.
      10. 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.
   2. 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. 2. Subject matter, the set-up and principle of the functionality of the API

   1. 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.
   2. The Client, which wants to use API functionality, must be verified and identified.
   3. The API integration procedure:
      1. 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 settings.
      2. 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.
      3. 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.
      4. In order to duly integrate the API functionality, the Client must:
         1. know the Client ID;
         2. know the API key;
         3. connect to the API using a valid IP address (Article 2.3.2 of the Agreement).
   4. 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.
   5. The Institution may at any time terminate the provision of the API service, ability to access the API, with or without due notice.
   6. 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.
   7. The API functionality is provided to the Client free of charge.
   8. 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.
   9. 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. 3. Parties’ obligations

   1. The Client undertakes to:
      1. 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;
      2. use only valid IP address to connect to the API;
      3. not to abuse the functionality of the API;
      4. ensure the security and integrity of the Account and the computer or interface accessible through the API;
      5. 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;
      6. be responsible for protecting the Client’s used technical measures, software, data and other systems against viruses, malware and other internet security risks;
      7. 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;
      8. 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;
      9. to comply with the security requirements listed in Article 4 of the Agreement.
   2. 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 the API; 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 the API.

4. 4. Security measures

   1. 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.
   2. Organisational security measures:
      1. Security policy and procedures for the protection of personal data
         1. 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.
         2. The security policy should be reviewed and revised on an annual basis.
      2. Roles and responsibilities
         1. Roles and responsibilities related to the processing of personal data should be clearly defined.
         2. Clear appointment of persons in charge of specific security tasks should be performed.
      3. Access control policy
         1. Specific access control rights should be allocated to each role (involved in the processing of personal data) following the “need to know” principle.
         2. 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.
         3. Access rights should be reviewed on annual basis and revoked as soon as they are no longer needed.
         4. (For High-risk cases) Roles with excessive access rights should be clearly defined and assigned to limited specific members of staff.
      4. Asset management
         1. 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.
         2. Roles having access to certain resources should be defined and documented.
         3. IT resources should be reviewed and updated on annual basis.
      5. Change management
         1. 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.
         2. 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.
      6. Data processors
         1. 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.
         2. Upon finding out of a personal data breach, the data processor shall notify the controller without undue delay.
         3. 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.
         4. The data controller’s organisation should regularly audit the compliance of the data processor to the agreed level of requirements and obligations.
         5. (For High-risk cases) The employees of the data processor who are processing personal data should be subject to specific documented confidentiality/non-disclosure agreements.
      7. Incident handling / Personal data breaches
         1. An incident response plan with detailed procedures should be defined to ensure effective and orderly response to incidents pertaining personal data.
         2. 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.
         3. The incidents’ response plan should be documented, including a list of possible mitigation actions and clear assignment of roles.
         4. (For High-risk cases) Incidents and personal data breaches should be recorded along with details regarding the event and subsequent mitigation actions performed.
      8. Business continuity
         1. 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 breach).
         2. A business continuity plan should be detailed and documented (following the general security policy). It should include clear actions and assignment of roles.
         3. 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.
      9. Confidentiality of personnel
         1. 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.
         2. 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 agreements.
         3. (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).
      10. Training
          1. 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.
          2. The Client should have structured and regular training programs for staff, including specific programs for the induction (to data protection matters) of newcomers.
          3. The Client should ensure that all of its employees receive training at least once a year.
   3. Technical security measures:
      1. Access control and authentication
         1. 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.
         2. 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.
         3. 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.
         4. User passwords must be stored in a “hashed” form.
      2. Logging and monitoring
         1. 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).
         2. Log files should be timestamped and adequately protected against tampering and unauthorised access. Clocks should be synchronised to a single reference time source.
         3. Actions of the system administrators and system operators, including addition/deletion/change of user rights should be logged.
         4. 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 activity.
         5. A monitoring system should process the log files and produce reports on the status of the system and notify for potential alerts.
      3. Server / Database security
         1. Servers should be configured in accordance with documented standards/procedures.
         2. Server images should be reviewed, tested and kept up to date (i.e. with recent patches and changes to build/configuration).
         3. 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.
         4. Database and applications servers should only process the personal data that are actually needed to process in order to achieve its processing purposes.
         5. (For High-risk cases) Encryption solutions should be considered on specific files or records through software or hardware implementation.
         6. (For High-risk cases) Encrypting storage drives should be considered.
      4. Workstation security
         1. Users should not be able to deactivate or bypass security settings.
         2. Users should not have privileges to install or deactivate unauthorised software applications.
         3. The system should have session time-outs when the user has not been active for a certain time period.
         4. Critical security updates released by the operating system developer should be installed regularly.
         5. (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).
         6. (For High-risk cases) Full disk software encryption should be enabled on the workstation operating system drives.
      5. Network / Communication security
         1. Whenever access is performed through the Internet, communication should be encrypted through cryptographic protocols (TLS).
         2. Wireless access to the IT system should be protected by encryption mechanisms.
         3. 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.
         4. The network of the information system should be segregated from the other networks of the data controller.
      6. Back-ups
         1. Backup and data restore procedures should be defined, documented and clearly linked to roles and responsibilities.
         2. Backups should be given an appropriate level of physical and environmental protection consistent with the standards applied on the originating data.
         3. Execution of backups should be monitored to ensure completeness.
         4. Backup media should be regularly tested to ensure that they can be relied upon for emergency use.
         5. Copies of the backup should be securely stored in different locations.
         6. In case a third-party service for backup storage is used, the copy must be encrypted before being transmitted from the data controller.
      7. Mobile / Portable devices
         1. Mobile and portable device management procedures should be defined and documented establishing clear rules for their proper use.
         2. Mobile devices that are allowed to access the information system should be pre-registered and pre-authorised.
         3. Mobile devices should be subject to the same levels of access control procedures (to the data processing system) as other terminal equipment.
         4. Personal data stored at the mobile device (as part of the organisation’s data processing operation) should be encrypted.
      8. Application lifecycle security
         1. During the development lifecycle best practices, state of the art and well acknowledged secure development practices, frameworks or standards should be followed.
         2. Specific security requirements should be defined during the early stages of the development lifecycle.
         3. 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.
         4. Secure coding standards and practices should be followed.
         5. During the development, testing and validation against the implementation of the initial security requirements should be performed.
         6. 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.
         7. Periodic penetration testing should be carried out.
         8. Information about technical vulnerabilities of information systems being used should be obtained.
         9. Software patches should be tested and evaluated before they are installed in an operational environment.
      9. Data deletion / disposal
         1. 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.
         2. Shredding of paper and portable media used to store personal data shall be carried out.
         3. (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).
      10. Physical security
          1. 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.
          2. Clear identification, through appropriate means, e.g. ID Badges, for all personnel and visitors accessing the premises of the organisation should be established as appropriate.
          3. 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 monitored.
          4. Intruder detection systems should be installed in all security zones.
          5. Vacant secure areas should be physically locked and periodically reviewed.
          6. An automatic fire suppression system, closed control dedicated air conditioning system and uninterruptible power supply (UPS) should be implemented at the server room.
   4. 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. 5. Compromise of authorization elements

   1. 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.
   2. 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.
   3. 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.
   4. 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.

6. 6. Liability

   1. 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.
   2. 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.

7. 7. Termination

   1. This Agreement could be terminated on any grounds specified in the General T&C or in the Account Agreement.
   2. 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.