Previous Next JavaScript must be enabled to correctly display this content

## 3.1 Account On-boarding

This topic describes about the creating the loan account.

One of the key expectations from financial institutions today is to provide a smooth, seamless, and fast customer journey, while ensuring compliance with all applicable regulatory requirements. As part of this broader objective, the Loan Account Onboarding process into the loan servicing system plays a critical role within the overall loan origination lifecycle.

The specific onboarding requirements can vary across financial institutions — ranging from straightforward account creation with basic data capture to fully comprehensive onboarding, where all loan, party, and collateral details are captured upfront to support immediate servicing and disbursal.

This section describes how the Loan Account Onboarding process works in the servicing system, ensuring consistency, compliance, and readiness for servicing operations immediately upon account creation.

The Loan Account Record is the central object created in the servicing system during onboarding. Each loan account is created directly in Active status, with all necessary details captured upfront. The Loan Account Record consists of the following sections:

For more information on creating the loan account, refer Retail Loans Origination User Guide

Basic Details

This section captures the core attributes of the loan account. These attributes form the foundational data required to onboard the account into the servicing system.

As part of Basic Details, the following information is captured:

- Account Number

  This is the unique identifier for the loan account in the servicing system. If Auto Generation of account numbers is enabled, this field is not required in the onboarding request — the system will automatically generate the account number. If auto generation is disabled, the account number must be provided in the request.

- Product Segment Code & Product Segment Type

  These fields identify the broader product segment to which the loan account belongs. The Product Segment Definition encapsulates multiple attributes common across lending products, such as eligibility criteria, regulatory reporting parameters, and operational policies.

- Product Code & Product Type

  These fields identify the specific product within the selected product segment. Each Product defines key operational aspects, including:

  Multiple products can exist under a product segment, each catering to different customer segments or loan purposes.

- Currency

  The currency of the loan account. This must match one of the currencies configured at the product level.

- Loan Amount

  The sanctioned loan amount, which must be explicitly provided during onboarding.

- First Installment Date

  This is the date the first installment becomes due.

- Account Onboarding Date

  The date the loan account is officially onboarded into the servicing system. This typically aligns with the disbursement date or account approval date.

- Account Open Date

  The date on which the account is officially considered "open." This may match the onboarding date but can be separately provided to align with regulatory reporting needs.

- Account Status

  This indicates the current lifecycle status of the loan account. At onboarding, this is always set to ACTIVE.

Party Information

As part of Party Information, the following details are captured:

- Party ID

  Unique identifier for each Party associated with the loan account. This could be an existing Party already present in the system or a newly created Party during onboarding.

- Primary Indicator

  This field identifies whether the Party is the Primary Party responsible for the loan or a Joint Party.

- Percentage Share

  For cases where there are multiple Parties associated with the loan, the user can capture the Percentage Share for each Party. This indicates the proportionate ownership or liability of each Party.

- Relationship Type

  This field captures the relationship between the Party and the loan — for example, Cosigner, Coborrower, or other applicable relationship types based on the institution’s policy.

Collateral Information

As part of Collateral Information, the following details are captured:

- Collateral IDs

  A list of Collateral IDs associated with the loan account. These IDs refer to records maintained in the Enterprise Collateral System.

- Collateral Type

  This is the type of collateral like Property, Vehicle, Jewellery etc that is securing the loan as defined in Enterprise collateral system.

- Linkage Type

  The allowed options are Primary or Secondary. Primary refers to collateral linked to the loan is a primary security used to cover the loan outstanding. Secondary security is for reporting purposes.

- Collateral category and Sub-category
  - Collateral category and Sub-category are further classification of collateral under the collateral type. Both these fields are optional and free text fields and additional information captured
  - Under collateral type property, Collateral category can be like UnderConstructionHome , FreeLand etc
  - Collateral sub-category can be like 2BHK, VILLA which is sub-classification under collateral category.
- Collateral currency

  This is the currency of the collateral linkage amount.

- Collateral Linkage Amount

  It is the amount of collateral value that is used for covering the loan outstanding. Collateral linkage amount need to be more than or equal to loan sanction amount Lets say, If a Collateral value is 10 Lakhs, for Loan sanction Amount of 5 Lakhs, collateral amount linked to loan can be 5 or any value greater than 5 lakhs.

- Collateral Details Management

  While the loan servicing system captures and links the Collateral IDs, all additional collateral details (such as valuation, lien details, and ownership) are managed directly within the Enterprise Collateral System. Any updates or modifications to collateral records must be performed in that system.

Disbursement Instruction Details

Multiple disbursement instructions can be captured in this section and for each disbursement instruction multiple Settlement Accounts can be captured. Each settlement record can have a distinct Settlement Mode and corresponding account details, providing flexibility in defining how the disbursement is to be processed and routed.

As part of Disbursement Details, the following information is captured:

- Disbursement Date

  The planned disbursement date for each disbursement segment, representing the valuedate of the disbursement. Multiple disbursement records can be captured on the sameday, with each record triggering a separate disbursement event.

- Disbursement Amount

  The planned disbursement amount recorded against each disbursement record.

- Itemization Type

  This field indicates the purpose of the disbursement. This field is non-mandatory and used primarily for reporting purposes.

- Disbursement Recipient / Disbursement To

  The recipient of the disbursement, such as a school, dealer, or customer.

- Settlement Details

  System allows capturing multiple Settlement Accounts for each disbursement record with distinct

  - Settlement Mode
  - Settlement Account details
  - Settlement Amount

  This enables the user to distribute a single disbursement amount across different settlement channels or accounts based on operational requirements.

- Settlement Mode

  Multiple disbursement settlement modes are supported based on look up type.

  SETTLEMENT_MODE:

  - Internal CASA accounts – Direct settlement within the institution’s internal accounts.

    Requires a valid Settlement Account, which must be an internal CASA account maintained within the bank’s core banking system.

  - The system validates the account status and currency against the disbursement currency.
- Ledger Account (LEDGER)
  - Requires a valid General Ledger (GL) Account.
  - This option is typically used for disbursements processed through cash transactions or internal ledger postings.
- External accounts via ACH – Settlement through Automated Clearing House (ACH) fordisbursements to external bank accounts.
  - Requires completion of ACH-related details (such as Routing Number, Account Number, and Account Type).
  - Used when the disbursement is processed to an external account through ACH or other electronic payment channels.
  - Following details are to be captured if settlement mode is External accounts via ACH. [Refer https://confluence.oraclecorp.com/confluence/display/OBRLS/Story+1%3A+ACH+-+OBPM+Integration to add below details]
    - ACH Routing no
    - Name on Account
    - Type of account
    - Standard Entry Class Code
- Settlement Account

  Account number to which settlement amount is to be disbursed. Based on settlement mode, internal CASA account no or ledger account number or external account number to be provided.

- Settlement Amount

  Settlement amount that is to be disbursed to settlement account. Sum of the Settlement amount across different settlement modes need to sum up to disbursement amount.

Auto Payment Instruction Details

As part of Auto Payment Instruction Details, the following information is captured:

- Activation Date

  The date from which the payment instruction becomes applicable.

- End Date

  The date until which the payment instruction remains applicable

Applicable Fees Information

As part of Applicable Fees Information, the following details are captured:

- List of Fees

  The list of fees applicable to the loan account.

- Fee Amount

  If the origination system overrides the default fee amount, the overridden value is captured.

- Satisfaction Options

  The user has three options to satisfy the fee:

  Pay Now – The fee is paid immediately.
- Pay Later – The fee remains due and will be settled later.
- Capitalize – The fee is added to the loan principal.
- Waived Fees

  If the fee is waived at the origination stage, it will be marked as waived and will not be applied

Stage Information

When defining a loan account, banks can structure the repayment schedule into multiple stages, each representing a different phase in the loan lifecycle. These stages dictate how interest and principal payments are handled over time, allowing flexibility based on the borrower’s financial situation.

For example, a loan might be structured as follows:

1. Moratorium (MOR) Stage – A grace period during which the borrower is not required to make any principal or interest payments. This is typically used for student loans, project finance, or loans with deferred repayment start dates.
2. Interest-Only Installment (IOI) Stage – A period where the borrower only pays interest, while the principal remains unchanged. This is common in real estate financing, where cash flows may not be immediate.
3. Equated Periodic Installment (EPI) Stage – The standard loan repayment phase, where the borrower repays both principal and interest in fixed periodic installments (e.g., monthly EMIs).

The transition from one stage to another is predefined in the loan agreement and configured during account onboarding. Each stage has its own duration, installment frequency, and end-period behavior, ensuring structured repayment aligned with the borrower’s cash flow and the bank’s risk management policies.

As part of Stage Information, the following details are captured:

- Stage Name

  A user-defined name for each stage, based on the bank’s naming convention.

- Stage Type
  The type of stage selected from a predefined list of stage types:
  - IOI – Interest Only Installment
  - EPI – Equated Periodic Installment
  - MOR – Moratorium
  - UDS- User Defined Schudule
- Duration

  The default duration for each stage, which is then applied at the account level.

- Installment Frequency
  The frequency at which installments are scheduled:
  - Monthly
  - Weekly
  - Biweekly
- End Period Behavior

  Defines how unpaid components (e.g., interest) are handled at the end of the stage’s term. Available options include:

- Capitalize Arrears – Unpaid amounts are added to the loan principal.
- Carry Forward to First Installment – Unpaid amounts are carried over to the first installment of the next stage.
- Excess Interest Treatment
  Specifies how excess interest (when the computed interest for a schedule period exceeds the installment amount) is handled:
  - Capitalize (CAPITALIZE) – Excess interest is added to the principal.
  - Carry Forward (CARRY_FWD) – Excess interest is carried forward to subsequent installments until it is fully adjusted.
  - Charge (CHARGE) – The excess interest is charged separately.

Interest Rate Preferences

The Interest Rate Preferences section defines how the interest rate is determined and applied to the loan account. This includes pricing mechanisms, spread configurations, and final rate calculations.

- Effective From (Resolved Date): Indicates the date from which the assigned interest rate becomes effective. The first period starts from the Account Opening Date.
- Pricing Type: Determines how the interest rate is set for the loan. Only the following options are applicable:
  - User Defined Rate: The interest rate is manually provided at the time of account onboarding.
  - Rate Code Based: The interest rate is derived from predefined floating rate codes.
- Rate Application: Specifies whether the interest rate remains constant or varies over time.
  - Fixed: The interest rate remains unchanged throughout the loan tenure, even if the rate code changes.
  - Floating: The interest rate updates dynamically based on modifications in rate codes.
- Spread Category: Multiple spread records can be captured, categorized under specific types to allow for detailed breakdowns.
- Spread: Captures or displays the resolved bank spread based on loan terms.
- Rate or Rate Code: Captures or displays the resolved interest rate based on the selected pricing method.
- Final Rate: The total interest rate applied to the loan, should be sent as:

  Final Rate = Interest Rate + Sum of All Spread

Insurance Information

Please refer to below link for adding insurance details. [https://confluence.oraclecorp.com/confluence/display/OBRLS/Insurance+Processing#InsuranceProcessing-AccountOnboarding]

Add details only for below field

- Component Code
- Premium Amount
- Currency
- Partner Code
- Insurance collection type

Common Settlement Details

This section allows capturing settlement details for Disbursement/Repayment instruction types. The settlement account details captured are used for execution of auto payment instructions or payment of fees / insurance collected as part of booking event. These account details are referred for auto disbursement as well if settlement accounts are not provided as part of disbursement schedule.

- Instruction Type-The purpose of this field is to identify the type of Settlement Instruction, whether for Disbursements or Repayments. For Disbursement only 1 Instruction can be captured while for Repayment multiple instructions can be captured.
- Account Currency- The cross currency Disbursements are not applicable and thus the Account Currency should be same as the Loan Account Currency.
- Priority -This field defines which settlement instruction to execute in priority for the Repayment. In case, the first settlement instruction is failing, the system should try for the next Settlement Instruction.
- Settlement Mode (CASA, Clearing, External Account)

Settlement Mode

Multiple disbursement settlement modes are supported based on look up type

SETTLEMENT_MODE:

- Internal CASA accounts – Direct settlement within the institution’s internal accounts. Requires a valid Settlement Account, which must be an internal CASA account maintained within the bank’s core banking system.
- The system validates the account status and currency against the disbursement currency.

Ledger Account (LEDGER)

- Requires a valid General Ledger (GL) Account.
- This option is typically used for disbursements processed through cash transactions or internal ledger postings.

External accounts via ACH – Settlement through Automated Clearing House (ACH) fordisbursements to external bank accounts.

- - Requires completion of ACH-related details (such as Routing Number, Account Number, and Account Type).
  - Used when the disbursement is processed to an external account through ACH or other electronic payment channels.
  - Following details are to be captured if settlement mode is External accounts via ACH. [Refer to https://confluence.oraclecorp.com/confluence/display/OBRLS/Story+1%3A+ACH+-+OBPM+Integration to add below details]
    - ACH Routing no
    - Name on Account
    - Type of account
    - Standard Entry Class Code

Bundling

Fee Benefit → Spread → Specific tenor

- Lookup Code → FEE_SPREAD will be introduced under Lookup definition for SPREAD_CATEGORY
  - Origination → Charge simulation request → passes the bundle code in addition to the present request inputs event-wise
  - The charge simulation service will be enhanced to pass the bundle code for CommonCore (PDS) to fetch the bundle benefits for the respective event
  - CommonCore (PDS) will process the charge simulation request by fetching the bundle benefits for the respective component based on the bundle code passed and shall return the following component-wise:
    - Component Code
    - Original Fee Amount
    - Bundle Margin Amount
    - Final Fee Amount
  - In event of the component in question not defined in the bundle code, the Bundle Margin Amount will be returned as 'Zero' wherein the computation will be as per the present support sans bundle benefits
  - The final fee amount will be included in the account onboarding request, as per the existing process
- Bundle Code, Bundle Type, Benefits Applicable Tenure and benefits applicable end-date will be stored against the respective loan account

Fee Benefit → Spread → Perpetual

- Origination → Charge simulation request → passes the bundle code in addition to the present request inputs event-wise
- CommonCore (PDS) will process the charge simulation request by fetching the bundle benefits for the respective component based on the bundle code passed and shall return the following component-wise:
  - Component Code
  - Original Fee Amount
  - Bundle Margin Amount
  - Final Fee Amount
- In event of the component in question not defined in the bundle code, the Bundle Margin Amount will be returned as 'Zero' wherein the computation will be as per the present support sans bundle benefits
- The final fee amount will be included in the account onboarding request, as per the existing process
- ·Bundle Code, Bundle Type, Benefits Applicable Tenure and benefits applicable end-date will be stored against the respective loan account. The benefits applicable end-date will be updated as the account maturity date

MLA Information

The MLA (Military Lending Act) Information section enables the bank to identify and process loans extended to customers who are Service Members on Active Duty or their covered dependents, in accordance with the Military Lending Act (MLA) regulations.

This section becomes applicable during Account Onboarding when the customer’s eligibility or status requires MLA compliance checks.

Purpose

Banks must ensure that all loans covered under MLA comply with Military APR limits. The MLA Information captured during onboarding forms the basis for subsequent Military APR (MAPR) validation.

Capturing MLA Details

When the customer applying for a loan is identified as a Service Member or dependent on active duty, the user should capture the following information.

MLA Applicable

- Indicates whether the account falls under Military Lending Act (MLA) applicability.
- This flag may be received from the Origination System or manually set by the user.
- When set to Yes, additional MLA fields become mandatory for input.

Service Member Party ID

- Unique identifier of the Service Member in the Party system.
- Used to link the loan account with the corresponding Service Member.

Active Duty Start Date

- Specifies the date from which the Service Member is on active duty.
- Determines the start of the MLA coverage period.

Active Duty End Date

- Indicates the end date of the Service Member’s active duty (if available).
- Optional field; may be left blank if the active duty period is ongoing.

Order Number

- Reference number of the military orders authorizing active duty service.
- Optional input for documentation and audit tracking.

Reference Number

- Unique identifier of the Active Duty record maintained in the Party system.
- Enables traceability and linkage between loan account and Party’s Active Duty record.

Parent topic: Operation