The goal of LibEuFin is to make the development and testing of FinTech applications easier. It hides implementation details of complex legacy banking APIs behind a simple interface.
LibEuFin has two main components:
The concept of a nexus user is used to implement access control to the operations that the nexus provides.
A user has a login name and a (salted, hashed) password. This is the HTTP basic auth method. (Other authentication methods could be added in the future.)
A nexus user can be marked as superuser. All permission checks are skipped for superusers. Only superusers are allowed to create/modify other users.
A bank account is the local representation of some bank account. The information stored about it includes:
Examples:
# Download latest transactions via the default bank connection and store them locally
$ http -a $USER:$PASSWORD POST \
https://example1.libeufin.tech/bank-accounts/my-acct/fetch-transactions
Bank connections connect the local LibEuFin bank account to the real bank. The bank connection includes the following data:
Bank connections provide the following actions:
Examples:
# Manually request the inter-day account report via the EBICS C52 order
$ http -a $USER:$PASSWORD POST \
https://example1.libeufin.tech/bank-connections/my-ebics-testacct/ebics/download/C52
# Download available bank accounts that can be accessed through this connection,
# according to the bank server (with EBICS, does a HTD request).
# For each of them, create a bank account resource in LibEuFin.
$ http -a $USER:$PASSWORD POST \
https://example1.libeufin.tech/bank-connection/my-ebics-testacct/fetch-accounts
Facades allow extra domain-specific functionality to be implemented on top of users, bank accounts and bank connections. A facade stores the following information:
The only facade currently supported by LibEuFin is the “Taler Wire Gateway API” layer. It provides a filtered view on the transaction history, a more restricted API to create payment requests, and a mechanism to create a counter-transaction for incoming transactions that do not conform to a certain format.
Examples:
# Request the Taler-specific history through the facade
$ http -a $USER:$PASSWORD \
https://example1.libeufin.tech/facades/my-taler-wire-gw/taler/history/incoming
The goal of access control in LibEuFin is to allow the following scenarios:
It is currently not planned to have more fine-grained permissions, such as spending limits or more fine-grained read/write permissions.
Users can be normal users or superusers. Permission checks do not apply to superusers, and only superusers can create other users.
Each top-level object (bank account, bank connection, facade) has a list of nexus users with write access, and a list of users with read access.
When using a bank connection through a bank account, permission checks must succeed for both the bank account and the bank connection.
This works differently for facades: A facade has a set of associated bank connections and bank accounts it can access. Permissions on these associated objects are checked when the facade is created. When invoking operations on the facade, the nexus only checks if the current nexus user can access the facade and not the underlying objects abstracted by the facade.