Minka Bridge

represents an entity that people trust to hold their deposits or process their payments.

Abstract

Minka Bridge represents a protocol to connect an entity that people trust to hold their deposits to the Cloud. The role of the Bridge is to enable IOU swap between credit in fiat, cryptocurrency, loyalty points and the Cloud.

Bridge allows:

• upload - exchange real world IOU for an cloud IOU (debit)

• download - convert cloud IOUs to real world IOUs (credit)

• or get status (balance or history) of an external system​

Context

Most of the financial products are not closed loop projects and need an interface with the real, legacy world. Available payment gateway and infrastructure if focused on the credit card processing that covers only a fraction of the population in cash based economies. Most of the transactions are made trough ACH and cash agents that use outdates technologies and concepts.

Building an interface to the legacy world can take months or years per institution and is the main obstacle to bring new technologies to the mainstream. Also, in most of the cash based economies the payment ecosystem is fragmented and differs from country to country.

That is why Minka developed a protocol that simplifies exchanging information between the Cloud and the Bridge based on the Ledger protocol and the open banking standards.

Since the current initiatives (PSD2 [1], Open Banking UK [2], Berlin Group [3], HKMA API [4]) are attending markets with high credit card and banking penetration, so we had to topicalize the standards to the reality of the cash based markets and include non-traditional financial institutions such as cash agents and credit unions.

Minka is looking to become the open banking standard for cash based economies.

[1] Payment Service Directive https://ec.europa.eu/info/law/payment-services-psd-2-directive-eu-2015-2366_en​

[2] Open Banking UK https://www.openbanking.org.uk/​

[3] The Berlin Group https://www.berlin-group.org/​

[4] HKMA API https://apidocs.hkma.gov.hk/​

Concepts

Keeper

Keeper is used to cryptographically sign each core transaction in Minka Cloud. Holding a keeper locally enables Bridge to hold private and immutable ownership of Signers and sign Actions. If Keepers are stored locally, transactions can be signed and encrypted offline.

Bridge uses Keeper to:

• generate Signer

• sign IOU claims (Action)

Router

Router is used as a mapping on the Bridge Wallet to that enable executing endpoints on Bridge side.

Router is set in the router property of the Wallet to map the Bridge endoints:

"router": {
    "routid": "blueBank",
    "upload": "{bank_url}/v1/credit",
    "downld": "{bank_url}/v1/debit",
    "status": "{bank_url}/v1/status"
}

The credentials to access the Bank endpoint are stored in the internal Router object in the Minka Cloud.

Open Banking Endpoints

Bridge needs to expose endpoints using JSON REST API interface.

Endpoints upload (debit) and download (credit) implement logic to perform and sign an Action on the Bridge side. Calling an endpoint is a request to sign a specific Action and preform internal operations on the Bridge core.

Bridge can expose REST API endpoints on their premises. Bridge need to enable HTTPS and the authentication method for Cloud to access their REST API.

Bridge Exposing Endpoints.

Adapter

Bridge can also expose REST API endpoints using Adapter by Minka. Adapter is microservice that exposes REST API and can be hosted in cloud or on the Bridge premise.

Bridge implements the internal logic to access its core systems, while the Cloud provides a secure channel between Router adapter and Bank infrastructure and provides an out-of-the-box implementation of the needed endpoints.

Adapter is a microservice contianer that can be hosted on the Bridge premise.

Bridge

Each Bridge is represented as a Wallet in the Minka Cloud.

Upload (debit)

Upload process executes the Action to send IOUs to the Cloud and debit on Bridge core.

The process has several steps to complete:

1. respond with upload action from Bridge limit Signer to the target Signer

2. implement logic to perform debit to the target account on Bridge core

3. sign the upload action and send to the Cloud

Download (credit)

Upload process executes the Action to receive IOUs from the Cloud and credit on the Bridge core.

1. respond with download action from the source Signer to the Bridge Signer

2. implement logic to perform credit to target account on Bridge core

3. sign the download action and send to TIN Cloud