8.19 Defining Transfer Pricing Methodologies Using Node Level Assumptions

In Oracle Asset Liability Management, your product portfolio is represented using the Product Dimension specified in your ALM Application Preferences. Node Level Assumptions allow you to define transfer pricing, prepayment, adjustment, and other ALM Rule assumptions at any level of the Product dimension Hierarchy. The Product dimension supports a hierarchical representation of your chart of accounts, so you can take advantage of the parent-child relationships defined for the various nodes of your product hierarchies while defining transfer pricing, prepayment, adjustment, and other ALM Rule assumptions. Child nodes for which no assumptions have been specified automatically inherit the methodology of their closest parent node. Conversely, explicit definitions made at a child level will take precedence over any higher-level parent node assumption.

Node level assumptions simplify the process of applying rules in the user interface and significantly reduce the effort required to maintain business rules over time as new products are added to the product mix. It is also not required for all rules to assign assumptions to the same nodes. Users can assign assumptions at different levels throughout the hierarchy.

If you want to transfer price the product hierarchy using the Spread from Interest Rate Code, then Transfer Pricing method accepts for the following products:

  • Mortgages: Transfer price them using the Zero Discount Factors cash flow-basedmethod.
  • Credit Cards: Transfer price all but secured credit cards using the Spread from NoteRate method.

To transfer price in this manner, you need to attach Transfer Pricing methods to the nodes of the product hierarchy as follows:

  • Hierarchy Root Node: Spread from Interest Rate Code
  • Mortgages: Zero Discount Factors CashFlow
  • Credit Cards: Spread from NoteRate
  • Secured Credit Cards: Spread from Interest RateCode

The transfer pricing method for a particular product is determined by searching up the nodes in the hierarchy. Consider the Secured Credit Cards in the above example. The Spread from IRC is specified at the leaf level, the system need not search any further to calculate the transfer rates for the Secured Credit Cards. However, for a Premium Credit Card, the system searches up the hierarchical nodes for the first node that specifies a method. The first node that specifies a method for the Premium Credit Card is the Credit Card node and it is associated with the Spread from Note Rate method.

Child nodes for which no assumptions have been specified automatically inherit the methodology of their closest parent node. So if neither a child node nor its immediate parent has a method assigned, the application searches up the nodes in the hierarchy until it finds a parent node with a method assigned, and uses that method for the child node. If there are no parent nodes with a method assigned, then the application triggers a processing error stating that no assumptions are assigned for the particular product or currency combination.

All parameters that are attached to a particular methodology (such as Interest Rate Code) arespecified at the same level as the method. If multiple Interest Rate Codes are to be used, depending on the type of the product, the method would need to be specified at a lower level. For instance, if you want to use IRC 211178 for Consumer Products and IRC 3114 for Commercial Products, then the transfer pricing methodologies for these two products need to be specified at the Commercial Products and Consumer Products nodes.

You need not specify prepayment assumptions at the same nodes as transfer pricing methods. For example, each mortgage category can have a different prepayment method while the entire Mortgage node uses the Zero Discount Factors cash flow method for transfer pricing.