8 Basic OBDX Configurations

OBDXCS application using the OBDXCS URL provided during environment setup.

Upon the first successful login, the SUPERADMIN user will automatically be assigned the AUTHADMIN role, which grants the required privileges to perform the initial administrative configurations within the system.

After login, the administrator should complete the following configuration activities to prepare the platform for further administrative setup and user onboarding.

Entity Maintenance

After logging into OBDX CS for the first time, the Entity Maintenance page is displayed as the default landing page.

Entity Maintenance allows the administrator to define and manage the bank entity within the system. This is a mandatory step required to ensure that the platform is correctly associated with the bank’s operational entity.

The administrator should review the entity details and ensure that the required information is correctly configured before proceeding with other system configurations.

For the detailed step-by-step process for Entity Maintenace, refer to the configuration document provided in the link below.

For more information, refer Entity Maintenance in Core User Manual.

System Configuration

The next step involves configuring key system parameters through the System Configuration module. This section allows administrators to define important system settings required for the operation of the OBDX platform.

During this step, the administrator should:

  • Provide values for the mandatory configuration fields
  • Review the default values provided by the system
  • Modify configuration parameters if required based on bank policies
  • Configure the required parameters at the module level based on the bank’s requirements.
  • Perform any module-specific configurations required for enabled modules
  • Configure the Email server settings required for sending system notifications and alerts
  • Define the Bank Name, which will be used in system-generated communications and alerts sent to users

Most mandatory fields are pre-populated with default system values. These values can be retained or modified based on the bank’s operational requirements.

For more information, refer System Maintenance in Core User Manual.

Locale Maintenance

By default, all supported languages are enabled in the system. The SUPERADMIN can disable languages that are not required and set the preferred default language for the application. This allows the bank to control which languages are available to users based on their requirements.

For the detailed step-by-step procedure for Locale Maintenance, refer to the document provided in the link below.

For more information, refer Locale Maintenance.

Touch Point Maintenance

Touch Point Maintenance is used to configure and manage the digital channels through which users can access the OBDX platform. This configuration allows the bank to define the available touch points and control how different banking services are made accessible across these channels. The SUPERADMIN must ensure that the required touch points are appropriately configured before enabling user access to the platform.

The following internal touch points are defined and available as part of the OBDX system:

  • Internet
  • Mobile App
  • Mobile Browser
  • Snapshot

For the detailed step-by-step procedure for configuring Touch Point Maintenance, refer to the document provided in the link below. Specifically, refer to the following sections in the document:

  • Touch Point Maintenance
  • Touch Point Group Maintenance

For more information, refer Touch Point Maintenance in Core User Manual.

For more information, refer Touch Point Group Maintenance in Core User Manual.

Role Maintenance

Role Maintenance is used to define and manage application roles within the OBDX platform, which control the transactions, widgets, dashboards, and privileges available to different users. Roles are defined for various user types such as Retail & Business, Corporate, and Admin, and can be mapped to both internal and external touch points.

Application roles determine the level of access a user has within the system. Users are able to view and perform only those transactions, menu options, widgets, and dashboards that are mapped to the roles assigned to them. System administrators can map entitlements, transactions, and privileges such as Perform, Approve, View, Release, and Check to specific roles based on the bank’s access control policies.

Roles can also be associated with specific entities, although this is optional. If no entity is mapped, the role will be available globally across all entities. Additionally, roles can be mapped to internal touch points (such as Internet, Mobile App) used directly by OBDX, or to external touch points used by third-party systems through defined scopes in the Identity Management System.

Proper role configuration ensures that users and external systems can access only the functionalities permitted by the bank’s security and operational policies.

For the detailed step-by-step procedure for Role Maintenance, refer to the document provided in the link below.

For more information, refer Role Maintenance in Core User Manual.

Limit Package Maintenance

Limit Package Maintenance is used to define and manage transaction limits within the OBDX platform. A limit package represents a group of transaction limits that can be applied to specific transactions or transaction groups. These limits are created through Limit Definition and can be mapped either to individual transactions or to transaction groups defined through Transaction Group Maintenance. Each limit package can also be associated with a specific channel or touch point, or with a group of touch points.

Limit packages allow the bank to control the maximum transaction values and usage thresholds across different users, parties, and channels. For Retail party transactions, the limit package assigned at the user level will be applied. For Business party transactions, the limit package configured at the party level through Party Preferences will be used.

Once created, limit packages can be mapped across various levels within the system, including Enterprise Roles (Retail, Corporate, or Administrator), User Segments, Parties, and Users. This enables the bank to apply different limit structures based on roles, customer segments, or specific users, ensuring compliance with internal policies and regulatory requirements.

For the detailed step-by-step procedure for Limit Package Maintenance, refer to the document provided in the link below. Specifically, refer to the following sections in the document:

  • Limits Definition
  • Limit Package Management

For more information, refer Limit Package Maitenance in Core User Manual.

System Rules Configuration

System Rules are used to define platform-level parameters for different enterprise roles, such as Retail, Corporate, and Administrator. It is important to note that within System Rules, only Limits support configuration at the Entity level and Touchpoint level is available.

For the detailed step-by-step procedure for configuring System Rules, refer to the document provided in the link below.

For more information, refer System Rules in Core User Manual.

Approval Configuration

To enable administrative activities within the system, the SUPERADMIN must configure an approval rule.

As part of the initial setup, it is recommended to create an Auto Authorization (AutoAuth) approval rule with minimum permissions required for user creation. This enables the administrator to quickly create additional administrative users required for further platform configuration.

Once additional administrators are onboarded, more structured maker-checker approval workflows can be configured as per the bank’s governance policies.

For the detailed step-by-step procedure for Approval Configuration, refer to the document provided in the link below. Specifically, refer to the following sections in the document:

  • User Group Management
  • Workflow Management
  • Approval Rule Management

For more information, refer Approval in Core User Manual.

User Onboarding Process

After completing the initial system setup, the SUPERADMIN is responsible for onboarding additional users required to operate and manage the OBDX platform. This includes onboarding Bank Administrative users (such as BANKADMIN or other admin roles) as well as customer users who will access digital banking services.

All users who require access to OBDX must first be created in Oracle Identity Cloud Service (IDCS). Once the user is created in IDCS, the user can then be onboarded into OBDX through the OBDX Admin application. Users cannot be created directly within the OBDX application; the user lifecycle must always begin in IDCS, followed by onboarding in OBDX.

The SUPERADMIN should initially create bank administrative users to support operational activities. Subsequently, customer users can be onboarded and provided access to the relevant digital banking services based on the roles and entitlements assigned to them.

For the detailed step-by-step process for creating users in IDCS and onboarding them into OBDX, refer to the SCIM configuration and user onboarding documentation provided in the link below.

IDCS User Creation: User Profile Maintenance.

OBDX User Onboarding:

  • Admin User Onboarding – Performed through User Management
  • Retail/Business User Onboarding – Performed through User Management
  • Corporate User Onboarding – Requires Party Preference Maintenance (one-time setup for each party) along with Group Corporate Onboarding

For more information, refer User Onboarding in Core User Manual.

Two-Factor Authentication (2FA) Configuration

Two-Factor Authentication (2FA) adds an additional layer of security to the OBDX platform by requiring users to verify their identity using two authentication factors before completing certain actions, such as login or transactions. This helps reduce the risk of unauthorized access and protects against identity theft and phishing attacks.

SUPERADMIN can configure 2FA for different user types (Retail and Corporate) and, where applicable, for user segments. In a multi-entity setup, authentication rules can be defined separately for each entity. If a user switches entities after login, the system may prompt for second-factor authentication again.

OBDX provides multiple authentication mechanisms, including OTP (delivered to the registered mobile number or email), security questions, and push notification–based authentication.

Two-factor authentication (2FA) is applicable to all transactions in OBDX, excluding login.

For the detailed step-by-step procedure for configuring Two-Factor Authentication, refer to the document provided in the link below. Specifically, refer to the following section in the document:

For more information, refer Authentication in Core User Manual.

Brand Management

Brand Management allows the bank to customize the look and feel of the OBDX application to align with its branding guidelines. Through this configuration, the bank can manage elements such as logos, color schemes, and other visual components that define the user interface and overall digital banking experience. This helps ensure a consistent brand identity across the digital banking platform.

For the detailed step-by-step procedure for configuring Brand, refer to the document provided in the link below. Specifically, refer to the following section in the document:

For more information, refer Experience Builder in Core User Manual.

Template Maintenance

Template Maintenance allows the bank to customize the format of downloadable documents for transactions that support downloads. Using this feature, the Bank Administrator can download the existing XSL template, modify it as required (for example, formatting or layout changes), and upload the updated template back into the system. The header.xsl template needs to be updated to configure the bank’s logo; this is mandatory.

This enables the bank to tailor transaction download formats according to its reporting or documentation requirements.

For the detailed step-by-step procedure, refer to the Template Maintenance documentation provided in the link below.

For more information, refer Template Maintenance in Core User Manual.

Note:

For security reasons, it is recommended to revoke or disable the SUPERADMIN access once all initial setup and configurations are completed. Ongoing administration activities should be performed using designated Bank Admin users with appropriate roles and maker-checker controls.