Creating Balanced Transactions
Creating Balanced Transactions
When utilizing the TrnAdd API, it is important to understand certain aspects of balancing. The cores do not automatically generate offsetting entries to balance the various related accounts. When choosing between the options below, it is advisable to code for both scenarios, as one financial institution (FI) may prefer the control offered by the Three-Step Transaction, while another may favor the simplicity of the One-Step Transaction. Please note that without proper setup on the FI side, the One-Step Transaction will not function as intended.
- Control of money movement to certain GL accounts is not needed: XferAdd does not have the balancing considerations required of TrnAdd.
- The transfer accounts are DDA/Sav/Club/Loan: XferAdd does not work with Time Deposits or GL Accounts.
- Link for XferAdd information: XferAdd
- The FED will still track the FI’s balance and will require TrnAdd requests to be done on the core to update not only the customer’s account but also GL accounts for settlement and FED/Correspondent balancing accounts on the core. Since the cores themselves are not receiving the ACH/Wire information there is no automatic money movement or tracking.
- Consult the FI for GL accounts and their balancing requirements as these will vary.
Three Methods To Balance General Ledger Accounts
Three Step Transaction
The Three-Step Transaction process requires three TrnAdd requests to be completed. Typically, if a consumer performs only a single TrnAdd request, the core system will create a one-sided transaction, and no money movement to a designated General Ledger (GL) account will occur automatically. The core system will debit/credit the customer’s account and subsequently debit/credit the application’s (Demand Deposits/Loans/Time Deposits) settlement GL account. Without additional TrnAdd requests to correct the balance inconsistencies, the financial institution (FI) will be out of balance or have a forced balance.
Use Case
- Step 1: First TrnAdd request to affect the customer’s account. This affects the Customer’s account and moves money to the applications settlement GL account.
- Step 2: Second TrnAdd request to move money from the settlement GL account. Each FI will have a different GL account that is used for their settlement account. and will need to be gathered from the FI.
- Step 3: Third TrnAdd request to move money into the GL account used for tracking with the TPV application. Each FI will have a different GL account that is used for their settlement account. and will need to be gathered from the FI.
- Step 1: TrnAdd to debit customer account for $550.00. The customer’s account was debited a total of 550 dollars. This includes 525 dollars for the transaction and a 25 dollar convenience fee.
- Step 2: TrnAdd to debit DDA Settlement. The consumer will then need to debit the settlement GL account for the 550. this removes the total amount for it to be placed into the proper GL account being used for balancing.
- Step 3: TrnAdd(s) for placing money into GL account being used for balancing. Perform a single TrnAdd request to move the total 550 to a single GL account.
OR
- Perform two TrnAdd requests; one to move the $525 transaction amount to a GL Settlement Account and the second TrnAdd request to move the $25 fee to an income GL account.
Concerns
The FI may wish to allocate the transaction amount across different GL accounts to facilitate easier balancing. This may necessitate additional TrnAdd requests based on their specific requirements. For instance, if a fee is included in the transaction amount, the customer may see a single amount in their account history, but the FI would prefer to record the fee and the transaction proceeds in separate GL accounts
Exceptions
When both accounts involved are within the same application, a TrnAdd request from DDA/SAV/Club to another DDA/SAV/Club would require only two TrnAdd requests. It is assumed that the transaction amounts will be identical, with a credit to one account and a debit to another for the same amount. Since the GL settlement account will generate both a debit and a credit for the same amount, these entries will offset each other, eliminating the need for additional TrnAdd requests.
One Step Transaction
One-Step transactions eliminate the need for additional offsetting GL TrnAdd requests. This means that only a single TrnAdd request is required to affect the customer’s account, with the system handling all subsequent money movements.
Requirements
- Will require the use of the GLInterfaceCode and SrcCode values within the TrnAdd request to correctly identify the TrnAdd request as One-Step.
- The FI will need to provide the appropriate GLInterfaceCode and SrcCode values once the necessary parameters are configured.
- If the FI is not familiar with One-Step Transactions, a support case should be logged to gain a proper understanding of the parameter setup.
Use Case
To test One Step transactions within the DMZ, a consumer may pass in a single TrnAdd API with the following values:
| Core | SrcCode | GLInterfaceCode |
|---|---|---|
| SilverLake | TP | 107 for a Credit TrnCodeCode and 108 for a Debit TrnCodeCode |
| CIF2020 | o | 175 for a DrCr of C and 176 for a DrCr of D |
| Core Director | P2P | 111800 for both Credit/Debit TrnCodeCode |
Concerns
- Applicable only to Demand Deposits (DDA, Savings, Christmas Club).
- Unlike the Three-Step Transaction, this process bypasses the settlement GL account and places the offset in the account designated by the FI. There is no option to break down the transactions as in the Three-Step Transaction example.
- There could be either one GLInterfaceCode for debits and a different one for credits OR a single GLInterfaceCode based on the core type.
Hybrid Transactions Setup
A Hybrid Transaction Setup would be a combination of One Step and Three Step Transactions within the same FI. This allows the use of One Step where additional separation of the transaction amount is not needed and Three Step where granular control of the money movement is needed.