MVP components of a mobile banking application

This section lists the MVP components of a banking application. The methodology of our approach is to analyze the SDK.finance API documentation to identify whether the needed functionality exists.

User Accounts

Registration

Used for new user sign up.

Response:

This is straightforward. The SMS is sent for account validation.

Viewing User Information

Used for new fetching and displaying current user information.

Response:

From this response, we can see the support for very useful features related to user accounts represented by these attributes:

• phoneVerified
• emailVerified
• countryCode
• business
• twoFactorsAuthEnabled
• transactionNotification
• authorizationNotification

Business Accounts

From the previous request, we can see

This means that business accounts and VAT are supported out of the box.

Updating Information

Used for new fetching and displaying current user information.

Response:

No surprises there.

It’s also worth noting that separate endpoints exist for updating business information: /profiles/my/business and updating the address: /profiles/my/address and updating additional information: /profiles/my/additional.

The requests to those endpoints are similar to updating the basic information.

Validating an Account

Validate a user account.

Response:

This is a straightforward validation request.

Verify a Document

Three endpoints exist for viewing, approving, and declining. These endpoints are intended to be used by the integrated documents verification service.

Banking Operations

Out of the box, the platform supports assigning an existing a bank account to a user, and it supports multiple wallets. These wallets are referred to as “coins” in the API.

Create a Bank Account

This is a functionality that will have to be specifically built for our purposes. The expected request can contain as little as the currency only, and the response can return the IBAN and additional bank details. To avoid having to rework the entire banking aspect of the platform, this account can then be assigned to the user and a “Coin” is created and linked to the account.

Assigning a bank account to a user:

Response:

The user details are automatically obtained by the logged-in user and are used to assign an account to a user.

Create a Coin / Wallet

A quick note: the platform requires an “issuer” to be defined first. These are used to set the currency of the coin.

Response:

The platform has a restriction of one wallet per issuer/currency. This needs to be modified in order to support multiple sub-accounts that hold the same currency.

Coins can be easily set as main, updated, and deleted.

Account Balance

If a coin is directly assigned to an account, we can query the coins to view the balance.

Repsonse:

Note that this request returns all wallets belonging to a user, but that shouldn’t be an issue if we’re reviewing a single wallet. We simply need to select the coin that matches the serial number in question.

Top Up from External Bank Account

There were some inconsistencies between the Postman examples and the documentation. The prerequisite of performing top-ups is to set commission profiles. The commission profiles are set per issuer/currency. The prerequisite for that is to create a contract. There also seems to be a restriction on who can perform top-ups. There should be a simplification of this process to allow setting global commission rates rather than going through multiple steps to achieve a simple result.

Response:

The response has a lot of details which are mostly the transaction information. For a simple user experience, we only need the status: ok, and the user can later check the transaction history for details. Note that additional customization is required to prevent users to perform cyclic top-ups from and to the same account.

As for receiving transfers initiated from other banks and mapping them to the correct accounts and coins, additional customization is required.

Issue Payment

This covers money transfer to a bank account outside the platform and it is well defined.

Response:

Same as the previous operation, this operation can be reviewed in the transactions history.

Transaction History

The official documentation shows extensive filtering options: dates, types, statuses, wallets, currencies, and supports sorting and pagination.

Response:

This also seems to work well for the purposes of a digital bank, but the same as the above two cases, the presentation needs to be readable by humans.

Currency Rates

This endpoint is used to view the current exchange rates.

Response:

As previously mentioned, commissions can be set on top of currency rates. That has a separate endpoint. Currency rates can also be adjusted manually, though, the intention is for them to be automatically adjusted to current rates.

Currency Exchange

The endpoint for exchanging currencies between two wallets owned by the same user.

Response:

This works as expected. While the platform doesn’t allow transfers between wallets that have different currencies, the transfer method can be extended to make use of this endpoint and perform the currency exchange on the fly.

The next part

In the next & final episode, we turn to the topic of costs. We will briefly touch on the costs relating to SDK.Finance, hosting, and development.

Scandiweb is a full-stack digital agency with expertise in FinTech, digital marketing, and eCommerce. If you have a problem or a question, we’ll be happy to find you an answer, just drop us a line at [email protected]!

Share on: