SaFi Bank Space : Postings library - Core transaction types

“This instruction transfers an amount from one Vault account to another, in the committed phase. Effectively this instruction debits a Vault customer and credits another for the same amount, yielding two postings.” (from TM documentation)

“This specialist instruction provides the ability to directly write postings to the Postings ledger. It is a powerful instruction that can be used to model financial movements that do not map to any of the other instruction types. In fact, it is possible to recreate all the other instruction types’ side effects using this instruction.” (from TM documentation)

This special instruction allows send funds between two customer’s accounts. Custom addresses can be defined in static parameters.

“This specialist instruction provides the ability to directly write postings to the Postings ledger. It is a powerful instruction that can be used to model financial movements that do not map to any of the other instruction types. In fact, it is possible to recreate all the other instruction types’ side effects using this instruction.” (from TM documentation)

This special instruction allows send funds from customer account to internal account. Custom addresses can be defined in static parameters only for debit account - customer’s account. Internal account’s address is always DEFAULT.

“This specialist instruction provides the ability to directly write postings to the Postings ledger. It is a powerful instruction that can be used to model financial movements that do not map to any of the other instruction types. In fact, it is possible to recreate all the other instruction types’ side effects using this instruction.” (from TM documentation)

This special instruction allows send funds between addresses on same account.

“This specialist instruction provides the ability to directly write postings to the Postings ledger. It is a powerful instruction that can be used to model financial movements that do not map to any of the other instruction types. In fact, it is possible to recreate all the other instruction types’ side effects using this instruction.” (from TM documentation)

This special instruction allows send funds from internal account to customer account. Custom addresses can be defined in static parameters only for credit side - customer’s account. Internal account’s address is always DEFAULT.

“This specialist instruction provides the ability to directly write postings to the Postings ledger. It is a powerful instruction that can be used to model financial movements that do not map to any of the other instruction types. In fact, it is possible to recreate all the other instruction types’ side effects using this instruction.” (from TM documentation)

This special instruction allows send funds from internal account to another internal account. Internal accounts addresses are always DEFAULT. Debit and credit accounts are defined statically in yaml definition of a transaction.

"This instruction credits a customer’s account in the committed phase, with no intent to further modify the state of the client transaction. It also debits an internal account to follow the double-entry accounting model.

An example use case is exposed by the FPS payment scheme’s inbound payment returns. The scheme dictates that inbound returns must be accepted by the receiving bank. The phase is committed for both postings because, as far as the scheme is concerned, the financial transaction has taken place on their books. Consequently, there is no use for an authorisation phase - Vault must accept these funds." (from TM documentation)

"This instruction debits a customer’s account in the committed phase, with no intent to further modify the state of the client transaction. It also credits an internal account to follow the double-entry accounting model.

For example, a payment integration might model a cash withdrawal as an outbound hard settlement." (from TM documentation)

"This instruction debits a customer account, and credits a provided internal account, with a pending outgoing phase. Effectively this instruction ringfences customer funds. When an outbound authorisation is created, it implicitly opens a client transaction that is to be mutated by other instructions at a later date.

An example use case for this instruction is a card payment at a petrol station. The scheme may request an authorisation of £100. Later, a settlement can be submitted against this client transaction to release the ringfenced funds and debit the customer’s account with a committed phase." (from TM documentation)

"If accepted, this instruction changes an existing client transaction. More specifically, an authorisation adjustment adjusts the amount authorised by an earlier authorisation.

In order to process an authorisation adjustment, the Postings API looks up the client transaction specified in the instruction and is able to infer its direction (inbound or outbound). Currently this instruction can only be chained to outbound client transactions because no use case for inbound authorisation adjustments has been identified. This instruction attempts to further debit (or credit) a positive (or negative) amount to a customer account, and credit (or debit) a provided internal account, both with a pending outgoing phase. Effectively this means that Vault increases (or decreases) the amount ringfenced by a client transaction.

An example of this is a hotel reservation:

An outbound authorisation is submitted when the hotel is booked.

A week later, the customer decides to extend their stay at the hotel; the hotel requests an authorisation adjustment to a higher amount.

At the end of the stay, the client transaction is settled using a settlement." (from TM documentation)

AuthorisationAdjustmentByReplacement is same transaction type as AuthorisationAdjustment with the difference in only one parameter:

• replacementAmount: Instead of delta amount you specify a new amount, to replace the existing authorized amount

"If accepted, this instruction closes an existing client transaction by releasing funds ringfenced by a client transaction. No instruction can be chained after a release.

In order to process a release, the Postings API looks up the client transaction specified in the instruction and is able to infer its direction (inbound or outbound). It calculates the amount of funds ringfenced and then makes the relevant postings (credit and debits) needed to offset these ringfenced funds. Effectively this means Vault reduces the amount ringfenced by this client transaction to zero." (from TM documentation)

“This is the most complex of the instruction types. It is used to convert ringfenced funds into actual posting (debits and credits) in the committed phase. In order to process a settlement, the Postings API looks up the client transaction specified in the instruction and is able to infer its direction (inbound or outbound).

For example, a settlement for an outbound client transaction has two fields which can be used in different ways: the amount field can be left empty and the final field can be set to true or false to indicate that the client transaction should be closed.

Let us look at how these fields let a caller model a complex financial process. Note that in the scenarios below, we do not discuss internal account movements, given that they mirror the movements on the customer accounts, and are documented in the Core API section.” (from TM documentation)