Transaction Types Used in Core Banking

Any transfer of funds between two bank accounts is recorded as a transaction. There are different types of transactions used in the financial world.

FintechOS allows you to manage the transaction types in the FintechOS Portal's the General Ledger Configurations -> Transaction Type menu. See more details about managing transaction types in the General LedgerUser Guide.

Before being approved and used within contracts, each banking product must have its allowed transaction types specified in the Associated Transaction tab. For more information, see Banking Product Factory.

Predefined Transaction Types

The following transaction types are predefined to be used within Core Banking processes:

  • Accruals and Provisions: represent funds set aside to cover future expenses. A provision is aimed at covering a probable future expense, or reduction in the value of an asset. An accrual is a type of provision where revenue or expenses are recorded when a transaction occurs rather than when payment is received or made.
  • Deposit Liquidation: represents the way of closing the deposit account, so the entire amount is transferred in the current account and the deposit account is closed. If the liquidation occurs at the maturity date, the interest will also be paid. If the liquidation occurs on any other day except the maturity date, the customer will receive the sight interest (if a sight interest is configured).
  • Disbursement: represents the actual delivery of funds from a bank account to the customer. The repayment schedule gets calculated or recalculated.
  • Early Repayment: represents the early return of funds previously borrowed from a lender. The repayment schedule is updated.
  • Early Termination Deposit: represents the way of closing the deposit account applicable when the deposit is terminated before schedule.
  • Interest capitalization: represents the addition of the unpaid interest value to the principal balance.
  • Loan Contract: represents a binding contract between two or more parties to formalize a loan process.
  • Overdraft Payment: represents an amount of money that a customer with a bank account is temporarily allowed to owe to the bank.
  • Payment Deposit: represents an amount of money paid into an account as part of a payment schedule.
  • Payment Holiday: represents taking a break of any number of installments for the generated schedule.
  • Repayment: represents the act of paying back money previously borrowed from a lender by manually repaying an installment from the schedule.
  • Repayment Notification: represents a notification sent for when a repayment is received. At the due date of every installment, an automatic notification is generated by Core Banking.
  • Reschedule Overdues: represents an operation where overdue installments are merged to the following installments and they are no longer collecting penalties. The repayments schedule gets updated.
  • Reschedule Debt: represents an operation that updates the balance with the amount rescheduled.
  • Top Up Account: represents adding more money to the account before the value drains down to zero.
  • Transfer between my bank accounts: represents the process of moving funds between the same customer's bank accounts.
  • Withdraw: represents removing funds from a bank account, savings plan, pension, or trust.
If a transaction type is marked as an automatic transaction (Is Automatic Transaction = True), then that transaction type cannot be selected in the Events page when creating contract events. Check the Operational LedgerUser Guide for more information about defining transaction types.

Read about which transaction types are typically used for each type of banking products in the Banking Product Factory user guides, within each banking product's Associated Transactions section.

Transaction Fees

Some transactions have a fee collected at the event validation for each contract. For these transaction, repayment notifications for those fees are automatically generated when an event gets to the Approved status. For Early Repayment transaction there is a repayment fee, and for Payment Holiday transactions there is a payment holiday fee. These fees are automatically selected from the banking product.

When defining the transaction type, within the General Ledger Configurations -> Transaction Type menu of the FintechOS Portal, you can select the commission type for the fee:

Let's say your contract uses a banking product that has this type of fee attached to it:

Core Banking uses that fee for collection at the event level, for example 4% out of 400 USD, thus the customer must pay 416 USD in order to make an early repayment. This amount is notified at the approval of the event.

For a payment holiday that affects future installments, only the payment holiday fee gets notified.

The transaction types used for loan contracts that collect a fee at event approval are the following:

  • Payment Holiday transactions, with an associated commission type of Payment Holiday Fee.

  • Reschedule Overdues transactions, with an associated commission type of Repayment Fee.

  • Early Repayment transactions, with an associated commission type of Repayment Fee.

Disbursements don't have this setup for collecting a fee at event approval.

The Core Banking system parameter ManualRepaymentFee, having a default value False, is used mostly for early repayment.

When the value of the ManualRepaymentFee parameter is False, the early repayment fee is not negotiable, and the fee values are selected exactly as they are defined in the banking product.

When the value of the ManualRepaymentFee parameter is True, the early repayment fee is negotiable, and the credit officer that is operating the contract event can change the default value that is coming out of the banking product. If the fee is a percentage, then they can change the fee percentage or the fee value. If the fee is not a percentage, then they can change only the fee value. Other related values are automatically updated.

In the example below, having a ManualRepaymentFee parameter set on True, Core Banking allows changing the default repayment fee percentage of 3.5% out of 500 USD to 10%, resulting in a fee for repayment amount of 50 USD.

Real-Time or Queued Transaction Processing

The transactions made on bank accounts can be processed in real-time, when the transaction is approved, or at a later time, after being placed in a queue and taken for processing by a specialized scheduled job. The real-time processing depends on the Real Time Process checkbox being selected or not at every transaction type's level:

Each time a transaction is performed on a bank account, the system verifies its transaction type's Real Time Process field. If the value is True, then the transaction is processed right away. If the value is False, then the transaction is inserted as a record in the FTOS_CB_BankAccountTransactionQueue entity, with the isProcessed attribute set to False and isWithError set to False. The Bank Account Transaction Queue Processing scheduled job runs every 1 minute, taking the top 10 records from the entity with the attribute isProcessed = False, and processing the transactions. Any errors encountered on processing are logged in the errorMessage attribute. The Bank Account Transaction Queue Cleanup scheduled job runs once each night and cleans up the already processed transaction records with isWithError = False.

The transactions within the queue can be viewed by users with administrator rights from the Bank Account Transaction Queue menu in Core Banking: