API usage agreement

1. 1. Definitions

   1. 2FA - Two Factor Authentication used for advanced account protection and more secure sign-in.
   2. Account Agreement - the Electronic Money and Payment Account Agreement concluded between the Institution and the Client.
   3. Agreement - this API Usage Agreement.
   4. 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.
   5. API key - encrypted unique user identifier, which is generated upon Client's request, to which particular authorizations for the Client's Account usage are assigned.
   6. API technical specifications - detailed specifications of the API functionalities, behavior, 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.
   7. Client - a legal entity (not a consumer) that has engaged into the Agreement.
   8. Client ID - unique code assigned to the Client, provided to the Client via an encrypted file.
   9. Client secret - authentication token which is used in addition to the API key in order to authorize the Client with the authentication server to avoid Client impersonation, provided to the Client via an encrypted file.
   10. General T&C - general terms and conditions of payment services, which, together with all amendments and additions, constitutes an integral part of the Agreement, shall be applied and interpreted together with it, taking into account the context.
   11. 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 Client's Account via API (the Client can select and specify several IP addresses).
   12. SCA - Strong Client Authentication used for card payments and confirmation of money transfers.
   13. 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

2. 2. Subject matter, the set-up and principle of the functionality of the API

   1. API functionality is intended for the Client that 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 that wants to use API functionality must be verified and identified.
   3. API integration procedure:
      1. The Client that wants to use 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 API. This address may subsequently be edited by the Client itself by confirming such an action with a 2FA.
      3. The Client shall implement the API functionality by itself in accordance with the API Technical Specifications. An 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 Client ID.
         2. Know the API key.
         3. Connect to API using a valid IP address (Article 2.3.2 of the Agreement).
   4. API functionality is provided in the API Technical Specification, which may vary from time to time, depending on the functionalities provided by the Institution. Institution does not take any responsibility due to changes to the API functionality, which may be change upon sole discretion of the Institution. Client is responsible to follow up all the changes to and updates of the API Technical Specification and adapt its systems and processes accordingly.
   5. Institution may at any time terminate the provision of 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 or SCA, therefore, the Client accepts and is duly responsible for all the risks arising therefrom.
   7. 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 takes no responsibility due to any downtime of the API or any functionality of it, inability to access or use the API or relevant services via API according to the API Technical Specification.

3. 3. Obligations of the parties via use of the API

   1. The Client's obligations:
      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 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 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 API, 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's obligations: 10. Execute payments initiated by the Client and allow other actions indicated in Article 2.4 of the Agreement. 11. Maintain the functionality of the API, correct and make the API updates and changes necessary for the proper functioning of the API. 12. 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 API.

4. 4. Security measures

   1. Each Client that decides to integrate API obliges to duly comply with the minimum organizational and technical data security requirements set herein that must be applicable within the Client's organization. These security requirements are designed in order to safeguard data that is processed via use of the API against corruption, loss or access from unauthorized third party.
   2. Organizational 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 that 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 that 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 organization'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 organization 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 art. 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 organization 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 organization and sign respective confidentiality and 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 programmers for staff, including specific programmers 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 unauthorized access. Clocks should be synchronized 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 authorized 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 unauthorized 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-authorized.
         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 organization'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-authorized personnel. Physical barriers should, where applicable, be built to prevent unauthorized physical access.
          2. Clear identification, through appropriate means e.g. ID Badges, for all personnel and visitors accessing the premises of the organization 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 Client takes all the risk, responsibility and obligation to cover possible damages if it does not follow the above-mentioned requirements.
   5. 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.
   6. 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.
   7. The Institution may inspect the Client and ask to provide proof that the aforementioned organizational and technical data security requirements are being met within the Client's organization.
   8. In case the Client does not comply and ensure the organizational and technical security requirements presented in this Article, the Institution may cease the provision of API functionality, terminate this Agreement and the Client may be obliged to cover all damages incurred by the Institution, if any.

5. 5. Compromise of authorization elements

   1. In the event the Client losses the confidentiality of any of the authorization measures indicated in Article 2 of the Agreement, which are used by the Client in order to access and use its Account via API, or there is a serious threat or suspicion that such authorization elements have become known to unauthorized 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 were primary assigned to the Client, from the approved IP list so that it would be impossible to further access Account via the API. Used API keys are never used again. In case the Client requires, the Institution could temporally or permanently block Client's Account as well.
   3. The Institution takes all necessary measures it deems appropriate and useful to prevent any possible consequences arising from compromise of the Client's authorization elements, however, the Client is solely responsible for ensuring the confidentiality and security of its used authorization 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 authorization elements.

6. 6. 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 conditions of the Agreement.