All requirements related to modifying existing features, fixing bugs, or developing new features are recorded in Jira. After implementation, a code review is performed by a developer who did not perform the original implementation. Subsequently, the change is accepted by another person and manually tested.
The SDK is regularly automatically tested using unit tests and screen tests. Builds delivered to banks on SFTP are automatically created using a Jenkins job, thus minimizing the possibility of manual error.
We use tools for static code analysis (e.g. Sonar), for detecting memory leaks and for dependency vulnerabilities scanning.
Source code is maintained in a private repository, which is only accessible to authorized personnel. All workstations have antivirus software and up-to-date OS versions.
Each user input is validated in the SDK (and subsequently validated on Dateio BE side). Errors within the SDK are processed and displayed to the user in a readable format. No parts of the code (methods, variables, line numbers, etc.) are displayed in errors. The SDK contains only the necessary code for its function.
Serious errors and security findings are prioritized for fixing. Both types are recorded, and the bank is immediately informed of their occurrence.
The SDK is regularly subjected to external penetration tests, which are primarily based on the OWASP Mobile Top 10. Any medium and higher findings are given priority for resolution. Dateio will provide results of these penetration tests upon request. We will provide the bank assistance in case it wants to conduct its own penetration testing of the SDK implementation in its banking application.
Documentation is maintained for the SDK on this pages, which includes a changelog and possible migration guide, among others.
If the SDK calls another application (e.g., email, maps), an "app chooser" is used instead of a specific application.
WebView is not used anywhere in the SDK. We considered its use as problematic, among other things, for security reasons.
Requests/responses are not cached in the SDK.
When implementing the SDK into banking application, banking app should already ensure following, as the SDK does not provide it further:
The SDK uses third-party libraries. List of currently used third party libraries is available here.
Before we plan upgrade to new version or add a new library, we will notify you in advance to agree on further steps and timeline.
Libraries are regularly checked for security vulnerabilities. If any such vulnerability is found, the library will be prioritized for an update to a version without the vulnerability.
The SDK only stores offer images on the device to reduce the amount of transferred data. No user identifiers (such as IDs, tokens, etc.) are stored permanently on the device or is in source code of the SDK. These identifiers are only stored in non-persistent memory after the SDK is configured.
The bank application is responsible for obtaining, storing, or modifying user identifiers or tokens.
The SDK requires minimal permissions for its functionality and uses these following permissions:
Any further permissions will be communicated and consulted before implementation into SDK.
In release build debugging is disabled. Shrinking is enabled and development logs are also disabled.
Next, check our SDK overview, or start with implementation for Android or iOS.