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 General Ledger Configurations -> Transaction Type menu. See more details about managing transaction types in the Operational LedgerUser Guide.

You can also manage transaction type records in the Innovation Studio's Product Factory > Banking Product Dictionaries > Transaction Type menu.

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:

Transaction Type Details Can Be Purged
Accruals and Provisions It represents the 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. No
Agreement It represents a binding contract between the bank and a third-party entity (agent, broker, insurer, etc.) to formalize an agreement to financially compensate the third-party for the intermediation of selling banking products or services to customers, or compensate the bank for the intermediation of selling the third-party's products or services to customers, and to compensate the bank for managing the contract with the third-party. Yes
Deposit Liquidation It 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). No
Disbursement It represents the actual delivery of funds from a bank account to the customer. The repayment schedule gets calculated or recalculated. Yes
Early Repayment It represents the early return of funds previously borrowed from a lender. The repayment schedule is updated. Yes
Early Termination Deposit It represents the way of closing the deposit account applicable when the deposit is terminated before schedule. Yes
Interest Capitalization It represents the addition of the unpaid interest value to the principal balance. No
Loan Contract It represents a binding contract between two or more parties to formalize a loan process. Yes
Overdraft Payment It represents an amount of money that a customer with a bank account is temporarily allowed to owe to the bank. No
Payment Deposit It represents an amount of money paid into an account as part of a payment schedule. No
Payment Holiday It represents taking a break of any number of installments for the generated schedule. Yes
Repayment It represents the act of paying back money previously borrowed from a lender by manually repaying an installment from the schedule. No
Repayment Notification It 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. No
Returned Amount or Goods It represents the transaction through which a customer returns all or part of a loan or mortgage in a short while after contract creation, if the banking product was defined to allow such transactions, and the commissions already paid by the customer as front-end fees marked as returnable are paid back. This transaction type only accepts Return Fee commission types. Upon transaction approval, a new contract version is automatically created. Yes
Reschedule Overdues It represents an operation where overdue installments are merged to the following installments and they are no longer collecting penalties. The repayments schedule gets updated. Yes
Reschedule Debt It represents an operation that updates the balance with the amount rescheduled. No
Third-Party Invoice It represents the invoice through which the amounts automatically calculated based on an agreement are recorded in Core Banking. Yes
Top-Up Account It represents adding amounts to the account before the value drains down to zero. Yes
Transfer between my bank accounts It represents the process of moving funds between the same customer's bank accounts. Yes
Withdraw It represents removing funds from a bank account. Yes
IMPORTANT!  
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.
The transaction types that cannot be purged (marked with No in the above table's Can Be Purged column) cannot be deleted from the system. Their To Be Purged field within the Transaction Type page is marked as False, cannot be edited and is hidden.
For each transaction type that can be purged (marked with Yes in the above table's Can Be Purged column), Core Banking displays a tab in the Records To Be Purged dashboard only if their To Be Purged field is marked as True.

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 transactions, 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.

NOTE  
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.

IMPORTANT!  
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: