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.
You can manage the transaction types in the FintechOS Portal's Admin Configurations -> Transaction Type or 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 FintechOS 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.
You can use the following transaction types are predefined in Core Banking processes:
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. Can't be purged.
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 inter-mediation of selling the third-party's products or services to customers, and to compensate the bank for managing the contract with the third-party. Can be purged.
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). Can't be purged.
Disbursement - It represents the actual delivery of funds from a bank account to the customer. The repayment schedule gets calculated or recalculated. Can be purged.
Early Repayment - It represents the early return of funds previously borrowed from a lender. The repayment schedule is updated. Can be purged.
Early Termination Deposit - It represents the way of closing the deposit account applicable when the deposit is terminated before schedule. Can be purged.
Interest Capitalization - It represents the addition of the unpaid interest value to the principal balance. Can't be purged.
Loan Contract - It represents a binding contract between two or more parties to formalize a loan process. Can be purged.
Overdraft Payment - It represents an amount of money that a customer with a bank account is temporarily allowed to owe to the bank. Can't be purged.
Payment Deposit - It represents an amount of money paid into an account as part of a payment schedule. Can't be purged.
Payment Holiday - It represents taking a break of any number of installments for the generated schedule. Can be purged.
Repayment - It represents the act of paying back money previously borrowed from a lender by manually repaying an installment from the schedule. Can't be purged.
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. Can't be purged.
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. Can be purged.
Reschedule Debt - It represents an operation that updates the balance with the amount rescheduled. Can't be purged.
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. Can be purged.
Third-Party Invoice - It represents the invoice through which the amounts automatically calculated based on an agreement are recorded in Core Banking.
Top-Up Account - It represents adding amounts to the account before the value drains down to zero. Can be purged.
Transfer between my bank accounts - It represents the process of moving funds between the same customer's bank accounts. Can be purged.
Withdraw - It represents removing funds from a bank account. Can be purged.
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 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, Core Banking displays a tab in the Records To Be Purged dashboard only if their To Be Purged field is marked as
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.
When you add events for contracts created based on current account banking products, the following transaction types can be selected, assuming that they were added previously at banking product level: Top-Up Account, Transfer between my bank accounts, Withdraw.
The transactions can be performed only in the same currency.
When you add events for contracts created based on term loan banking products, the following transaction types can be selected, assuming that they were added previously at banking product level: Disbursement, Early Repayment, Payment Holiday, Repayment Notification, Reschedule Overdues, Reschedule Debt.
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, 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
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.
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
BankAccountTransactionQueue entity, with the
isProcessed attribute set to
isWithError set to
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.
As a user with admin rights, you can view the transactions within the queue in the Bank Account Transaction Queue menu: