Patent Publication Number: US-8538840-B2

Title: Financial services data model

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application claims the benefit of U.S. Provisional Patent Application No. 60/435,461, filed Dec. 20, 2002, which is herein incorporated in it&#39;s entirety by reference. 
    
    
     TECHNICAL FIELD 
     The described technology relates generally to data modeling and particularly to modeling of business information. 
     BACKGROUND 
     Various business entities, such as companies, store information electronically in furtherance of their business needs. These companies may have extensive databases of information that include customer tables, supplier tables, employee tables, and so on. The schemas and data models associated with these databases may be customized to help meet the business needs of the company. For example, an automotive manufacturer may organize information about its customers in a way that is very different from the way that an online bookstore may organize information about its customers. Even within a single company, that company may use many different application programs that employ very different schemas and data models. For example, a customer relationship management application program may use a data model that is very different from the data model used by an accounting program. The use of customized data models by a company and by applications within the company has the advantage of allowing information to be modeled in a way that is appropriate for the business needs of the company. Unfortunately, because of this diversity in the data models, it is not easy for the company to share its information with other companies or for applications to share their information. 
     The financial industry has been plagued by data models for financial information that are customized to individual financial institutions and thus make it difficult for financial institutions to share information. For example, major credit reporting services provide their credit reports in very different formats and with very different types of information. As a result, credit reports from different reporting services are typically stored in a raw format without any schema or data structure associated with the reports. Thus, the financial institutions that receive these credit reports cannot effectively automate the processing of the information on the credit reports. As another example, financial institutions may use very different models to store data relating to applications for different types of financial products (e.g., loan applications, brokerage account applications, and checking account applications). The data models for these applications are typically customized to support the “standard” applications electronically, but they cannot accommodate “non-standard” applications electronically. In addition the application models for different types of applications may be customized to each type of application. As an example, a financial institution may have a loan application data model and a separate checking account application data model. As described above, such diversity in application data models makes it difficult for financial institutions and financial application programs to share financial information. 
     Various attempts have been made to define standard data models so that information can be more easily shared between companies and applications. For example, the Open Applications Group has defined a standard data model that can be used by companies and applications when sharing information. A problem with these data models is that they do not provide effective ways to model relationships between various parties, such as a person or a company. In addition, if a company or an application developer wants to customize the standard data model, the customized data model may not be compatible with future upgrades of the standard data model. It would be desirable to have a data model that would more effectively model relationships and facilitate the upgrading of customizations of the data model. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  illustrates the highest level data elements of the party class. 
         FIG. 2  illustrates the data elements of the listOfRelationship class in one embodiment. 
         FIG. 3  illustrates the data elements of the representedBy class in one embodiment. 
         FIG. 4  illustrates the data elements of the customerOf class in one embodiment. 
         FIG. 5  illustrates the data elements of the contactOf class in one embodiment. 
         FIG. 6  illustrates the data elements of the employeeOf class in one embodiment. 
         FIG. 7  illustrates the data elements of the org class. 
         FIG. 8  illustrates the data elements of the baseData data element of the org class in one embodiment. 
         FIG. 9  illustrates the data elements of the person class. 
         FIG. 10  illustrates a data elements of the baseData data element of the person class in one embodiment. 
         FIG. 11  illustrates the data elements of the busUnit class in one embodiment. 
         FIG. 12  illustrates the data elements of the baseData element of the busUnit class in one embodiment. 
         FIG. 13  is a block diagram illustrating the interconnection between business various systems and a universal business application network. 
         FIG. 14  is a block diagram illustrating the overall architecture of a universal business application network in one embodiment. 
         FIG. 15  is a flow diagram illustrating the process of adding custom data to a party class. 
         FIG. 16  is a flow diagram illustrating the process of creating a customer relationship for a party in one embodiment. 
         FIG. 17  is a diagram illustrating data elements of the financialApplication class in one embodiment. 
         FIG. 18  is a diagram illustrating data elements of the financialStatement class in one embodiment. 
         FIG. 19  is a diagram illustrating data elements of the listOfAsset class in one embodiment. 
         FIG. 20  is a diagram illustrating data elements of the listOfLiability class in one embodiment. 
         FIG. 21A  is a diagram illustrating data elements of the listOfIncomeSource class in one embodiment. 
         FIG. 21B  is a diagram illustrating data elements of the listOfExpense class in one embodiment. 
         FIG. 22  is a diagram illustrating data elements of the financialApplicationAccount class in one embodiment. 
         FIG. 23  is a diagram illustrating data elements of the collateral class in one embodiment. 
         FIG. 24  is a diagram illustrating data elements of the loanPurpose class in one embodiment. 
         FIG. 25  is a diagram illustrating data elements of the listOfFundingSource class in one embodiment. 
         FIG. 26  illustrates the data elements of the financialAccount class in one embodiment. 
         FIG. 27  illustrates the data elements of the baseData data element of the financialAccount class in one embodiment. 
         FIG. 28  illustrates the data elements of the balanceData data element of the financialAccount class in one embodiment. 
         FIG. 29  illustrates the data elements of the creditData data element of the financialAccount class in one embodiment. 
         FIG. 30  illustrates the data elements of the demandDeposit data element of the financialAccount class in one embodiment. 
         FIG. 31  illustrates the data elements of the interestData data element of the financialAccount class in one embodiment. 
         FIG. 32  illustrates the data elements of the investmentData data element of the financialAccount class in one embodiment. 
         FIG. 33  illustrates the data elements of the loanData data element of the financialAccount class in one embodiment. 
         FIG. 34  illustrates the data elements of the termData data element of the financialAccount class in one embodiment. 
         FIG. 35  illustrates the data elements of timeDeposit data element of the financialAccount class in one embodiment. 
         FIG. 36  illustrates the data elements of relatedProduct data element of the financialAccount class in one embodiment. 
         FIG. 37  illustrates the data elements of relatedParty data element of the financialAccount class in one embodiment. 
         FIG. 38  illustrates the data elements of the holding class in one embodiment. 
         FIG. 39  illustrates the data elements of the baseData data element of the holding class in one embodiment. 
         FIG. 40  illustrates the data elements of the security class in one embodiment. 
         FIG. 41  illustrates the data elements of the securityData data element of the security class in one embodiment. 
         FIG. 42  illustrates the data elements of the creditBureauReport class in one embodiment. 
         FIG. 43  illustrates the data elements of the baseData data element of the creditBureauReport class in one embodiment. 
         FIG. 44  illustrates the data elements of the creditData data element of the creditBureauReport class in one embodiment. 
         FIG. 45  illustrates the data elements of the creditReason data element of the creditBureauReport class in one embodiment. 
         FIG. 46  illustrates the data elements of the financialAccountData data element of the creditBureauReport class in one embodiment. 
         FIG. 47  illustrates the fraudActivity data element of the creditBureauReport class in one embodiment. 
         FIG. 48  illustrates the inquiryType data element of the creditBureauReport class in one embodiment. 
         FIG. 49  illustrates the summaryData data element of the creditBureauReport class in one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
     A data model that allows for relationships between entities, also referred to as parties, to be modeled as attributes of an entity and for the data model to be customized in a manner that facilitates upgrading of the data model is provided. In one embodiment, the data model defines a party class that includes a party identifier and a list of relationships of that party with other parties. The relationships may include represented-by relationships, customer-of relationships, contact-of relationships, or employee-of relationships. The party class can be sub-classed (i.e., be a base class for a derived class) depending on the type of party that is being modeled. The types of parties may include a business unit, household, organization, person, and so on. A business unit is generally a corporation, division, or group of individuals that provides services or products for the organization (e.g., company) that is using the data model. A household is a group of individuals who commonly share the same dwelling and compose a family or social unit. An organization is an institution, a corporation, an administrative and functional structure with a common purpose, or other grouping of people. A person is an individual. A customer is a person, organization, or household who uses products or services provided by a business unit. An employee is a person employed by an organization. A contact is a person serving as a representative, messenger, or liaison for an organization or another person. A representative is a person who represents an organization or another person. The data model models the relationships as attributes associated with a party. For example, a person may have a customer relationship with several different business units. In such a case, the data model specifies that information relating to each business unit would be associated with that person. In one embodiment, the data model is specified using a schema language such as XML Schema. 
     In one embodiment, the data model defines a hierarchy of the data elements for describing a party. The data model may define data elements that are complex. A complex data element is a data element that comprises data sub-elements. For example, an address data element may be a complex data element that includes street, city, and state data sub-elements. The data model may specify custom data elements at various places within the hierarchy of data elements. A custom data element is of a custom data element type. The custom data element type initially defines no data elements. The data model can be customized by defining custom data elements for the custom data element type. For example, the data elements relating to the relationship of an employee of an organization may have a custom data element through which data elements relating to the salary history of the employee can be defined. Because the custom data elements are defined at various places within the hierarchy, the customizations of the data model can be associated with related data elements within the hierarchy. 
     Table 1 lists the data elements of a party class in one embodiment. The indentation of the data element names indicates data sub-elements of complex data elements. For example, the addressRelationshipData data element of line  10  includes the data sub-elements of endDate, occupancyTypeCode, startDate, and typeCode. These data sub-elements may themselves be complex data elements with data sub-elements (not shown in the table). For example, the startDate data element of line  13  could have data sub-elements of year, month, and day. Lines  28 - 85  list the data elements that define the various relationships of the party. Lines  15 ,  35 ,  57 ,  63 ,  70 ,  84 ,  85 , and  86  list customData elements of a type appropriate for the enclosing complex data element. For example, the customData element defined at line  35  allows for custom data to be defined that relates to the enclosing representedBy complex data element. 
     
       
         
           
               
               
             
               
                 TABLE 1 
               
               
                   
               
             
            
               
                 1. 
                 party 
               
               
                 2. 
                  id 
               
               
                 3. 
                  communicationData 
               
               
                 4. 
                   . . . 
               
               
                 5. 
                  listOfAddress 
               
               
                 6. 
                   address 
               
               
                 7. 
                    id 
               
               
                 8. 
                    baseData 
               
               
                 9. 
                    . . . 
               
               
                 10. 
                    addressRelationshipData 
               
               
                 11. 
                     endDate 
               
               
                 12. 
                     occupancyTypeCode 
               
               
                 13. 
                     startDate 
               
               
                 14. 
                     typeCode 
               
               
                 15. 
                    customData 
               
               
                 16. 
                  listOfAlternateId 
               
               
                 17. 
                   alternateId 
               
               
                 18. 
                  listOfLicenseData 
               
               
                 19. 
                   classCode 
               
               
                 20. 
                   countryCode 
               
               
                 21. 
                   expiryDate 
               
               
                 22. 
                   issueDate 
               
               
                 23. 
                   number 
               
               
                 24. 
                   province 
               
               
                 25. 
                   stateCode 
               
               
                 26. 
                   suspensionEndDate 
               
               
                 27. 
                   typeCode 
               
               
                 28. 
                  listOfRelationship 
               
               
                 29. 
                   listOfRepresentedBy 
               
               
                 30. 
                    representedBy 
               
               
                 31. 
                     person 
               
               
                 32. 
                     relationshipData 
               
               
                 33. 
                      jobTitle 
               
               
                 34. 
                      statusCode 
               
               
                 35. 
                     customData 
               
               
                 36. 
                  listOfCustomerOf 
               
               
                 37. 
                   customerOf 
               
               
                 38. 
                    busUnit 
               
               
                 39. 
                    relationshipData 
               
               
                 40. 
                     historyCode 
               
               
                 41. 
                     satisfactionRatingCode 
               
               
                 42. 
                     statusCode 
               
               
                 43. 
                     typeCode 
               
               
                 44. 
                     listOfBillingProfile 
               
               
                 45. 
                      id 
               
               
                 46. 
                      baseData 
               
               
                 47. 
                       billTypeCode 
               
               
                 48. 
                       billFrequencyCode 
               
               
                 49. 
                       billDay 
               
               
                 50. 
                       budgetBillFlag 
               
               
                 51. 
                       mediaTypeCode 
               
               
                 52. 
                       manualBillCount 
               
               
                 53. 
                       manualBillVerificationReason 
               
               
                 54. 
                      . . . 
               
               
                 55. 
                      paymentMethodData 
               
               
                 56. 
                      relatedParty 
               
               
                 57. 
                      customData 
               
               
                 58. 
                    householdCustomerData 
               
               
                 59. 
                     demographicSegmentCode 
               
               
                 60. 
                     lifecycleStatusCode 
               
               
                 61. 
                     marketSegmentCode 
               
               
                 62. 
                     annualRevenue 
               
               
                 63. 
                    customData 
               
               
                 64. 
                  listOfContactOf 
               
               
                 65. 
                   contactOf 
               
               
                 66. 
                    org 
               
               
                 67. 
                    relationshipData 
               
               
                 68. 
                     jobTitle 
               
               
                 69. 
                     statusCode 
               
               
                 70. 
                    customData 
               
               
                 71. 
                  listOfEmployeeOf 
               
               
                 72. 
                   employeeOf 
               
               
                 73. 
                    org 
               
               
                 74. 
                    relationshipData 
               
               
                 75. 
                     currentEmployerFlag 
               
               
                 76. 
                    endDate 
               
               
                 77. 
                    jobTitle 
               
               
                 78. 
                    number 
               
               
                 79. 
                    occupationCode 
               
               
                 80. 
                    startDate 
               
               
                 81. 
                    typeCode 
               
               
                 82. 
                    userName 
               
               
                 83. 
                    yearsEmployed 
               
               
                 84. 
                   customData 
               
               
                 85. 
                  customData 
               
               
                 86. 
                 customData 
               
               
                   
               
            
           
         
       
     
     Table 2 lists the data elements of the business unit class in one embodiment. The business unit class inherits the party class as indicated by line  1 . 
     
       
         
           
               
               
             
               
                 TABLE 2 
               
               
                   
               
             
            
               
                 1. 
                 busUnit:party 
               
               
                 2. 
                  baseData 
               
               
                 3. 
                   name 
               
               
                 4. 
                  customData 
               
               
                   
               
            
           
         
       
     
     Table 3 lists the data elements of the household class in one embodiment. The household class inherits the party class as indicated by line  1 . 
     
       
         
           
               
               
             
               
                 TABLE 3 
               
               
                   
               
             
            
               
                 1. 
                 household:party 
               
               
                 2. 
                  baseData 
               
               
                 3. 
                   name 
               
               
                 4. 
                   familyTypeCode 
               
               
                 5. 
                   numberOfPeople 
               
               
                 6. 
                   annualIncome 
               
               
                 7. 
                   netWorth 
               
               
                 8. 
                   uniqueName 
               
               
                 9. 
                  customData 
               
               
                   
               
            
           
         
       
     
     Table 4 lists the data elements of the organization class in one embodiment. The organization class inherits the party class as indicated by line  1 . 
     
       
         
           
               
               
             
               
                 TABLE 4 
               
               
                   
               
             
            
               
                 1. 
                 org:party 
               
               
                 2. 
                  baseData 
               
               
                 3. 
                   name 
               
               
                 4. 
                   dunsNumber 
               
               
                 5. 
                  customData 
               
               
                   
               
            
           
         
       
     
     Table 5 lists the data elements of the person class in one embodiment. The person class inherits the party class as indicated by line  1 . 
     
       
         
           
               
               
             
               
                 TABLE 5 
               
               
                   
               
             
            
               
                 1. 
                 person:party 
               
               
                 2. 
                  baseData 
               
               
                 3. 
                   firstName 
               
               
                 4. 
                   lastName 
               
               
                 5. 
                   fullName 
               
               
                 6. 
                   middleName 
               
               
                 7. 
                   shortName 
               
               
                 8. 
                   nameSuffix 
               
               
                 9. 
                   titleCode 
               
               
                 10. 
                   genderCode 
               
               
                 11. 
                   maritalStatusCode 
               
               
                 12. 
                   birthDate 
               
               
                 13. 
                   annualIncomeAmount 
               
               
                 14. 
                   dependents 
               
               
                 15. 
                   ethnicityCode 
               
               
                 16. 
                   homeOwnerFlag 
               
               
                 17. 
                  customData 
               
               
                   
               
            
           
         
       
     
     Each of the types of a party specify a custom data element for that type. For example, the customData data element of the person class in Table 5 may be defined as being a PersonCustomDataType. If so, the person class can be customized by adding data elements to the definition of the PersonCustomDataType. The definition may be stored in a file that is separate from the file in which the person class is defined. A portion of an XML schema that defines the custom data for a personClass is
         &lt;xs:element name=“customData” type=
           “custom:PersonCustomDataType” minOccurs=“0”/&gt;
 
where “custom:” specifies a file that contains the definition of PersonCustomDataType, which may be
   
           &lt;xs: complexType name=“PersonCustomDataType”&gt;
           &lt;xs:annotation
               &lt;xs:documentation&gt;
                   Define the custom data element for this type following this annotation   
                   &lt;xs:documentation&gt;   
               &lt;/xs annotation&gt;   
           &lt;/xs:complexType&gt;       

       FIGS. 1-12  are block diagrams illustrating the data model in one embodiment. One skilled in the art will appreciate that the name of each data element is descriptive of the information stored in the data element.  FIG. 1  illustrates the highest level data elements of the party class in one embodiment. The highest level data elements include id  101 , communicationData  102 , listOfAddress  103 , listOfRelationship  104 , and customPartyData  105  data elements. The id data element may be a unique identifier of a party. The communicationData data element includes listOfPhoneNumber  106 , listOfEmail  107 , and listOfWebPage  108  data elements that provide communication information relating to the party. The listOfAddress data element contains a list of addresses for the party (e.g., a P.O. box and residence address for a household). The listOfRelationship data element defines data elements for describing various types of relationships. The customPartyData data element initially contains no data elements, but custom data elements can be added by defining data elements in the PartyCustomDataType. 
       FIG. 2  illustrates the data elements of the listOfRelationship class in one embodiment. The listOfRelationship class includes listOfRepresentedBy  201 , listOfCustomerOf  203 , listOfContactOf  205 , and listOfEmployeeOf  207  data elements that contain zero or more instances of the corresponding data sub-elements  202 ,  204 ,  206 , and  208 . The listOfRelationship class also includes a customData  209  data element with a type of listOfRelationshipCustomDataType that initially is defined to have no data elements. 
       FIG. 3  illustrates the data elements of the representedBy class in one embodiment. The representedBy class includes person  301 , relationshipData  302 , and customData  303  data elements. The relationshipData data element includes the jobTitle  304  and statusCode  305  data elements. Each of the customData data elements described in  FIGS. 1-12  has a unique type that initially has no data elements defined. 
       FIG. 4  illustrates the data elements of the customerOf class in one embodiment. The customerOf class includes busUnit  401 , relationshipData  402 , householdCustomerData  403 , and customData  404  data elements. The busUnit data element identifies the type of the business unit. The relationshipData data element includes statusCode  405  and typeCode  406  data elements. The householdCustomerData data element includes demographicSegmentCode  407 , lifecycleStatusCode  408 , marketSegmentCode  409 , and annual Revenue  410  data elements. 
       FIG. 5  illustrates the data elements of the contactOf class in one embodiment. The contactOf class includes org  501 , relationshipData  502 , and customData  503  data elements. The relationshipData data element includes jobTitle  504  and statusCode  505  data elements. 
       FIG. 6  illustrates the data elements of the employeeOf class in one embodiment. The employeeOf class includes org  601 , relationshipData  602 , and customData  603  data elements. The relationshipData data element includes number  604  and userName  605  data elements. 
       FIGS. 7-12  illustrate the inheritance of the party class by the classes of the entities. Each of these classes inherit the party class and define a baseData element that is specific to that class and a customData data element.  FIG. 7  illustrates the data elements of the org class in one embodiment. The org class inherits the party class  701  and includes baseData  702  and customData  703  data elements.  FIG. 8  illustrates the data elements of the baseData data element of the org class in one embodiment. The baseData data element includes name  801  and dunsNumber  802  data elements. 
       FIG. 9  illustrates the data elements of the person class. The person class inherits the party class  901  and includes baseData  902  and customData  903  data elements.  FIG. 10  illustrates data elements of the baseData data element of the person class in one embodiment. The baseData element includes firstName  1001 , lastName  1002 , fullName  1003 , middleName  1004 , shortName  1005 , nameSuffix  1006 , titleCode  1007 , genderCode  1008 , maritalStatusCode  1009 , birthDate  1010 , annualIncomeAmount  1011 , dependents  1012 , ethnicityCode  1013 , and homeOwnerFlag  1014  data elements. 
       FIG. 11  illustrates the data elements of the busUnit class in one embodiment. The busUnit class inherits the party class  1101  and includes baseData  1102  and customData  1103  data elements.  FIG. 12  illustrates the data elements of the baseData  1102  element of the busUnit class in one embodiment. The baseData data element includes the name  1201  data element. 
       FIG. 13  is a block diagram illustrating the interconnection between various business systems  1302  and a universal business application network. The universal business application network  1301  serves as an integration hub for the business systems  1302 . The architecture of the universal business application network  1301  allows new business applications that access legacy business systems to be developed with minimum customization. The legacy business systems can be provided by a single business organization or by different business organizations. The universal business application network  1301  also allows the business applications to exchange information using the party class. In one embodiment, the universal business application network uses the XML and Web services standards. 
       FIG. 14  is a block diagram illustrating the overall architecture of a universal business application network in one embodiment. The hub of the universal business application network is the business integration server  1410  that connects to the various business systems  1401  via adapters  1402 . The business integration server includes a transport layer  1411 , an object model  1412 , transformation stores  1413 , a business process controller  1414 , and a business process store  1415 . The transport layer is a mechanism through which business information is exchanged between the business systems and the business integration server. Each business system may have an adapter that is appropriate to the protocol of the transport layer. For example, the transport mechanism may use communications protocols such as TCP/IP. The transport layer may provide a messaging service for queuing, for guaranteeing delivery of messages, and for handling both synchronous and asynchronous messaging, such as that provided by IBM MQSeries and TIBCO Rendezvous. The adapters relay events from the business systems to the integration server and can import configurations of the business systems into the business integration server. In addition, the universal business application network may include encryption and authentication mechanisms to ensure the security and integrity of the information. For example, authentication will help ensure that a business process is accessing the intended business system, rather than an impostor business system. The object model or data model may contain the definition of various business-related objects such as a party, a business unit, a household, an organization, and a person. The objects may be defined using standard object definition tools such as an XML schema definition tool. The transformation store contains transformations for transforming information received from the business systems to the format used by the object model, and vice versa. For example, a person object may include a globally unique identifier for each person. A transformation for a business system that does not use globally unique identifiers may need to access an identification server to determine the globally unique identifier for each person. The transformations may be specified as a computer program, an XML Stylesheet Language Transform (“XSLT”), etc. The business process store contains the business processes that have been defined. A business process may be specified as a script, a process flow, an executable program, etc. In one embodiment, the business processes are defined using the Web Services Flow Language (“WSFL”). The business processes orchestrate a sequence of steps across multiple applications provided by the business systems to achieve a business objective. The business process controller coordinates the execution of the business processes. The business process controller may instantiate objects and invoke functions of the objects in accordance with the various business processes. The business process controller may also initiate the execution of business processes based on predefined conditions and events. For example, the business process controller may launch a certain business process each time an alert is received. The business integration network may provide a standard library of business routines (not shown) that may be invoked by the business processes. For example, a standard business routine might be to identify whether two person objects represent the same individual or to apply business rules to various objects and take the appropriate action as defined by those rules. The business integration server may also include various tools to facilitate the development of business processes. These tools may aid in developing transformations, defining common objects, and writing process flows. 
     The computers (e.g., a universal business application network computer and a business systems computer) may include a central processing unit, memory, input devices (e.g., keyboard and pointing devices), output devices (e.g., display devices), and storage devices (e.g., disk drives). The memory and storage devices are computer-readable media that may contain instructions that implement the business system. In addition, the data structures and message structures may be stored or transmitted via a data transmission medium, such as a signal on a communications link. 
       FIG. 15  is a flow diagram illustrating the process of adding custom data to a party class. In block  1501 , the schema for the party class is retrieved. The schema may be an XML schema file that includes a customData data element of a type that is defined in another file. In block  1502 , the schema for the types of custom data is retrieved. The schema may be stored in an XML schema file that contains the definition for each type of custom data. In block  1503 , the custom data schema is opened. In block  1504 , the tags relating to the custom data type of interest are located. In block  1505 , the custom data elements are added to the located tags. In block  1506 , the custom data schema with the newly defined data elements added to the custom data type is closed. 
       FIG. 16  is a flow diagram illustrating the process of creating a customer relationship for a party in one embodiment. In block  1601 , the component creates party objects for various parties. In block  1602 , the component identifies the customer relationships between parties. In block  1603 , the component selects a party that is a customer in a customer relationship. In decision block  1604 , if all such customers have already been selected, then the component completes, else the component continues at block  1605 . In block  1605 , the component selects the next customer relationship for that party. In decision block  1606 , if all the customer relationships for the selected party have been selected, then the component loops to block  1603  to select the next party that has a customer relationship, else the component continues at block  1607 . In block  1607 , the component adds to the party object of the selected party the identifier of the party that the selected party is a customer of. The component than loops to block  1605  to select the next customer relationship for the selected party. 
     Financial Application 
     A financial application is a collection of data representing a request by a party to open an account with a financial institution. For example, a person who wants to purchase a home will provide application data so that a bank can lend money to purchase the home. The application data may include the name of the party purchasing the home, the loan amount, down payment amount, and so on. When a financial application is approved, a financial institution then opens the appropriate accounts for the party, such as a mortgage account, a checking account, etc. 
     In one embodiment, a financial application data model is provided that supports applications by multiple applicants for multiple types of accounts in a single application. For example, using a single application, a husband, wife and child may apply for a residential mortgage in the husband and wife&#39;s name, a savings account in the wife&#39;s name, and a credit card account in the child&#39;s name. 
     In such a case, the party associated with the application will have three applicants (the husband, the wife, and the child) and the application will be associated with three types of accounts (i.e., a mortgage account, a savings account, and a credit card account). Accordingly, in some embodiments, each financial application for a party may include a list of financial accounts applied for, and for each account applied for, a list of the applicants from the party that are to be identified with the account. In this way, a single application may be used to apply for multiple accounts for multiple applicants, even though not all applicants within a party will be associated with each account applied for. 
     The financial application data model supports storing all information necessary to represent this application in a single data structure. In addition, the financial application data model allows financial statement information to be defined in a separate financial statement data model that is referenced by the financial application data model. Like the financial application data model, the financial statement data model allows multiple applicants to be associated with (i.e., related to) the financial statement, along with their percentage of ownership of listed assets. The financial statement data model also stores an effective date (“as of date”) of the financial statement. In addition, the financial statement data model can represent various liabilities of the applicant in a way that includes rating information derived from information provided by the organization (e.g., lender) associated with that liability. 
     Because financial statements are associated with financial application records, each financial statement record may be assigned a party identifier. When a financial application record is created, the appropriate financial statement records are identified using the party identifier and then associated with the financial application record. For example, if a party consists of a husband and wife, the identified financial statements may include a financial statement for the wife, a financial statement for the husband and a joint financial statement. 
     The financial application data model may include a primary flag for each account designated as a primary account. If, during the application process, the application is not approved with respect to the primary account, then the application will be completely rejected. In contrast, if an application for a non-primary account is rejected, then the application for the other accounts may still be accepted. The designation of the primary account is typically provided by a financial institution associated with the accounts being applied for. 
     The financial application data model may also allow for the collecting and storing of information relating to the financial account or accounts that will ultimately be created if the application is approved. Accordingly, once nascent accounts become actual accounts, information provided in the financial application can then be accessed via a financial account data model at some time during or after the application process. 
       FIG. 17  is a diagram illustrating data elements of the financialApplication class in one embodiment. The financialApplication class  1700  includes identifier  1701 , baseData  1702 , listOfApplicant  1703 , listOfFinancialApplicationAccount  1704 , listOfFinancialStatement  1705 , listOfRelatedApplication  1706 , and customData  1707  data elements. The baseData  1702  data element relates to the originating institution of the application and includes data elements representing bank name, bank identifier, branch identifier, region identifier, service center identifier, ownership code, priority code, application source code, sales stage code, and sales method application. The listOfApplicant  1703  data element allows multiple applicants (e.g., husband, wife, and child) to be associated with this application. Each applicant can have different roles (e.g., primary applicant, secondary applicant, and guarantor). The listOfFinancialApplicationAccount  1704  data element allows the applicants to apply for multiple accounts (e.g., line of credit account and checking account) in a single application. The listOfFinancialStatement  1705  data element allows multiple financial statements to be associated with this application (e.g., the husband and wife may have a combined financial statement that is separate from their child&#39;s financial statement). The listOfRelatedApplication  1706  data element allows multiple related applications (e.g., prior applications) to be associated with this application. 
       FIG. 18  is a diagram illustrating data elements of the financialStatement class in one embodiment. The financialStatement class  1800  includes identifier  1801 , baseData  1802 , listOfRelatedApplicant  1803 , listOfAsset  1804 , listOfLiability  1805 , listOfIncome Source  1806 , listOfExpense  1807 , and customData  1808  data elements. The financialStatement class thus represents assets, liabilities, income sources, and expenses of the applicants identified as related to this financial statement. The baseData data element includes an asOfDate data element that contains the effective date of the financial statement. The financial statement thus represents a snapshot of the related applicants&#39; financial information as of that date. 
       FIG. 19  is a diagram illustrating data elements of the listOfAsset class in one embodiment. The listOfAsset class  1900  optionally includes multiple asset  1901  data elements. Each asset data element includes a baseData  1902  data element that includes reference number, description, category code, value amount, and percent loan data elements. The percent loan data element indicates the percentage of this asset owned by the related applicants. For example, if the asset is a business that an applicant equally co-owns with a non-applicant, then the percent owned would be fifty percent. If the co-owner, in contrast, is listed as a related applicant on the financial statement, then the percent owned would be 100 percent. The assets may include real estate, savings, investments, and so on. 
       FIG. 20  is a diagram illustrating data elements of the listOfLiability class in one embodiment. The listOfLiability class  2000  optionally includes multiple liability  2001  data elements. Each instance of a liability data element corresponds to a liability (e.g., alimony and automobile loan) reported on the financial statement. The liability data element includes a baseData  2002  data element. The baseData  2002  data element includes account number, consolidated code, description, frequency code (i.e., frequency of the payment), payment amount, payout amount (i.e., total payout of liability including principal and interest), type code, value amount (e.g., current loan amount), rating code (e.g., satisfactory and derogatory), and related organization (i.e., creditor of the liability) data elements. The rating code corresponds to the rating provided by the related organization. 
       FIG. 21A  is a diagram illustrating data elements of the listOfIncomeSource class in one embodiment. The listOfIncomeSource class  2110  optionally includes multiple incomeSource  2111  data elements. Each incomeSource data element corresponds to an income source (e.g., alimony and trust payouts) associated with the related applicants of the financial statement. The incomeSource data element includes a baseData  2112  data element. The baseData data element includes amount, frequency code, type code, and description data elements. 
       FIG. 21B  is a diagram illustrating data elements of the listOfExpense class in one embodiment. The listOfExpense class  2121  optionally includes multiple expense  2122  data elements relating to various expenses (e.g., rent). The expense data element includes a baseData  2123  data element that contains amount, comments, description, frequency code, and type code data elements. 
       FIG. 22  is a diagram illustrating data elements of the financialApplicationAccount class in one embodiment. The financialApplicationAccount class contains information (e.g., collateral description, loan purpose, and account type) for the account being applied for. The financialApplicationAccount class  2200  includes identifier  2202 , baseData  2203 , decisionData  2204 , relatedProduct  2205 , listOfCollateral  2206 , listOfLoanPurpose  2207 , listOfRelatedApplicant  2208 , relatedFinancialAccount  2209 , listOfFundingSource  2210 , and customData  2211  data elements. The baseData  2203  data element includes a primaryFlag data element that indicates whether this account is the primary account associated with the application. The decisionData  2204  data element includes decision and decision reason data elements indicating the decision and reason made regarding the application account. The relatedProduct  2205  data element identifies the financial product associated with this account that is the type of account being applied for. The listOfCollateral  2206  data element identifies collateral (e.g., the vehicle that is the subject of an automobile loan) associated with the application. The listOfLoanPurpose  2207  data element lists various purposes for the loan. The listOfRelatedApplicant  2208  data element lists the applicants related to this financial application account. The relatedFinancialAccount  2209  data element identifies a potential financialAccount object to be created if this account is approved. The listOfFundingSource  2210  data element identifies the funding sources for this account (e.g., source of down payment for a mortgage account). 
       FIG. 23  is a diagram illustrating data elements of the collateral class in one embodiment. The collateral class  2300  includes identifier  2301 , baseData  2302 , propertyData  2304 , surveyData  2305 , insuranceData  2306 , titleInsuranceData  2307 , lienData  2308 , valuationData  2309 , regulationData  2310 , and customData  2311  data elements. The baseData  2302  data element includes category code, description, complete code (e.g., purchase of a custom-made boat), exclude indicator code, new used code, collateral reference number, percent owned (i.e., lending percentage of the collateral), price code, price date, and value amount data elements. The propertyData  2304  data element contains information about the property in a real estate transaction. The information includes CRA (Community Reinvestment Act) community, date purchased, lot size, number of baths, etc. The surveyData  2305  data element contains survey information and includes block number, book number, census tract, etc. The insuranceData  2306  data element includes a flood insurance flag, a flood zone indicator, insurance agent number, etc. The lienData  2308  data element includes lien holder, lien position, etc. The valuationData  2309  data element includes customer estimated value, current mortgage value, estimated annual taxes, etc. The regulationData  2310  data element includes loan type code, decision date when a decision is expected, occupancy code, etc. 
       FIG. 24  is a diagram illustrating data elements of the loanPurpose class in one embodiment. The loanPurpose class  2400  includes a baseData  2402  data element. The baseData  2402  element includes purpose (e.g., remodel), description, and primary flag data elements. The primary flag data element indicates whether this purpose is the primary purpose for the loan. 
       FIG. 25  is a diagram illustrating data elements of the listOfFundingSource class in one embodiment. The listOfFundingSource class  2500  optionally includes multiple fundingSource  2501  data elements. The fundingSource  2501  data element includes identifier  2502 , baseData  2503 , bankAccountData  2504  or creditCardData  2505 , statusData  2506 , and customData  2507  data elements. The baseData  2503  data element includes funding method code, funding amount, payment address, and contact name data elements. The statusData  2506  data element includes verification status code and verification comment data elements. 
     Financial Accounts 
     Once an application is approved, financial institutions and account holders can use a financial account data model for representing accounts in a way that allows for efficient account servicing and account inquiries. In some embodiments, the financial account data model is a flexible, multipurpose model that can be applied to almost any type of account or financial product type, including checking accounts, savings accounts, mortgage loan accounts, holding accounts, securities accounts, credit card accounts, etc. Thus, the financial account data model allows a flexible all-in-one approach for managing financial accounts. The flexible financial account data model also facilitates servicing, accessing, and aggregating a customer&#39;s financial account information. 
     In one embodiment, a single financial account data model applicable to multiple types of financial products including investment products, deposit products and credit products is provided. Account information that is received according to this data model corresponds to a plurality of data elements associated with the financial account data model, including a base data element for information applicable to almost any type of account. The data model also provides additional, more specialized data elements that are associated with attributes for specific financial products or groups of financial products. 
     Examples of some of the processes that may benefit from the financial account data model include processes associated with application processing, application status requests, fund verification requests, credit score requests, check order requests, credit score requests, fraud check requests, and credit approval requests. Other examples include processes associated with certificate of deposit service accounts, deposit service accounts, brokerage accounts, account creation, and account synchronization. 
     Because some financial products, such as investment products (e.g., securities) may generate the need for additional specialized data collection, various specialized data elements may be employed via the financial accounts data model. For example, with respect to securities accounts, a securities data model for representing a securities product type supported by the provided financial account data model may be provided along with the financial account data model. When a party provides account information, some of the information relating specifically to the securities account may be stored in one or more securities records which may then be accessed via the financial account record for the party. 
     Additionally, by making use of relationship definitions between various collaborating entities within an enterprise system (consisting of, for example, banks, credit unions, financial investment companies, credit bureaus, etc.), such entities may use the financial account data model to support the servicing of various types and instances of service accounts offered within the enterprise. For example, a customer may approach a banker and request the current balance on her checking account. The bank (i.e., front end) system locates a customer record for the customer. A bank system server then contacts an integration system server requesting summary information for each type of account (e.g., a checking account, certificate of deposits, brokerage account, etc.) the customer can hold. The integration system server then contacts appropriate external systems (i.e., back end systems) for each identified account type and requests that the external systems provide summary data. Once the external systems provide the information to the integration system server, the integration system server returns the account data to the requesting bank system server. In some embodiments, the front end (e.g., bank) system may then aggregate the account data and display the latest balance information for all of the customer&#39;s accounts on a summary view. In addition to obtaining information for the checking account, the customer can also inquire into the current balance of his CDs and brokerage accounts without the bank having to process another request. 
     A financial account data model may be implemented using a financialAccount class. Two classes related to the financialAccount class—a holding class and a security class—support use of the financial account data model with securities accounts and holdings. A holding is a way of associating a single stock symbol (i.e., ticker) with information on an initial buy of shares, and subsequent events that happen, such as buying additional shares, selling shares, and stock splits. 
     The security class comprises all of the common components of a securities account, such as productType data, securityData, and a customData component provide additional custom data attributes. 
       FIG. 26  illustrates the highest level data elements of the financialAccount class in one embodiment. The financialAccount class inherits from a party class, a product class, a holding class, and a custom class. The highest level data elements of the financialAccount class include id  2601 , baseData  2602 , balanceData  2603 , creditData  2604 , demandDepositData  2605 , interestData  2606 , investmentData  2607 , loanData  2608 , termData  2609 , timeDepositData  2610 , relatedProduct  2611 , relatedParty  2612 , relatedHolding  2613 , and customData  2614 . The id element  2601  may include a unique identifier of a custom account. The customData element  2614  may include miscellaneous information regarding a customer&#39;s account, such as customer preferences. The remaining high level data elements are described in more detail below in the text accompanying  FIGS. 27-37 . 
       FIG. 27  illustrates the data elements of the baseData element  2602  of the financialAccount class in one embodiment. The baseData elements include currencyCode  2701  (e.g., US, CA, etc.), account name  2702  (e.g., personal checking), account number  2703 , openDate  2704  (i.e., date account was opened), statusCode  2705  and typeCode  2706 . 
       FIG. 28  illustrates the data elements of the balanceData element  2603  of the financialAccount class in one embodiment. The balanceData elements relate to the balance information for the account and include availableBalanceAmount  2801 , currentBalanceAmount  2802 , and openingBalanceAmount  2803 . 
       FIG. 29  illustrates the data elements of the creditData element  2604  of the financialAccount class in one embodiment. The creditData elements include a limit element  2901  that can be used to indicate the account&#39;s limit, for example, in the case of a credit card account. 
       FIG. 30  illustrates the data elements of the demandDeposit element  2605  of the financialAccount class in one embodiment. The demandDeposit element includes an overdraftProtectionAccountNumber  3001  data element, which refers to the account number that a customer indicates as providing overdraft protection in case the account referred to exceeds its limit, as specified, for example, in creditData limit element  2901 . 
       FIG. 31  illustrates the data elements of the interestData element  2606  of the financialAccount class in one embodiment. The interestData elements include annualPercentageRate  3101  and annualPercentageYield  3102 . 
       FIG. 32  illustrates the data elements of the investmentData element  2607  of the financialAccount class in one embodiment. The investmentData element includes a marketValue element  3201 . This element provides a total market value for the account. 
       FIG. 33  illustrates the data elements of the loanData element  2608  of the financialAccount class in one embodiment. The loanData elements include amortization  3301 , baseRateIdentifier  3302 , fixedRateFlag  3303  (indicates whether loan rate is fixed), paymentFrequencyCode  3304 , rateBasis  3305 , and rateSpread  3306 . 
       FIG. 34  illustrates the data elements of the termData element  2609  of the financialAccount class in one embodiment. The termData elements include termCount  3401  and termUnitCode  3402 . These elements relate to the investment attributes of a financial account. 
       FIG. 35  illustrates the data elements of the timeDeposit element  2610  of the financialAccount class in one embodiment. The timeDeposit elements include autoRenew  3501 , gracePeriodCode  3502 , interestFrequencyCode  3503 , and maturityDate  3504 . 
       FIG. 36  illustrates the data elements of the relatedProduct element  2611  of the financialAccount class in one embodiment. Financial products can include various accounts, securities, and holdings. The relatedProduct elements include id  3601 , which refers to the ID number of a particular product related to the account, such as another type of account or holding. 
       FIG. 37  illustrates the data elements of the relatedParty element  2612  of the financialAccount class in one embodiment. The relatedParty elements include person  3701 , organization  3702 , and roleData  3703 . The  3701  and  3702  data elements refer to the person or organization related to the account, such as a guarantor or other related party. Their role is indicated by the roleData element  3703 . 
     The holding class and the security class support use of the financialAccount class for securities and holding accounts.  FIG. 38  illustrates the highest level data elements of a holding class in one embodiment. The holding class inherits from the common class, a security class, and the custom class. The highest level data elements of the holding class include idData  3801 , baseData  3802 , relatedSecurity  3803 , and customData  3804 . As with the financialAccount class, the idData element  3801  may be a unique identifier of a customer&#39;s holding account. The customData element  3804  may include miscellaneous information regarding the holding account, such as customer preferences, etc. In one embodiment, the baseData element  3802  may include various elements, as illustrated in  FIG. 39 . In one embodiment, the baseData elements may include costBasis  3901  (i.e., total cost basis of a financial services holding), currentAmount  3902  (i.e., total current value of a financial services holding), and quantity  3903  (e.g., “fifty shares”). 
       FIG. 40  illustrates the highest level data elements of the security class in one embodiment. The highest level data elements include idData  4001 , baseData  4002 , salesData  4003 , configurationData  4004 , priceType  4005 , relatedinvoiceLocation  4006 , relatedBusinessUnit  4007 , and customData  4008 . Additionally, two data element types related to the security class include securityData  4009  and customData  4010 . The securityData element  4009  is shown in further detail in  FIG. 41 . 
       FIG. 41  illustrates the data elements of the securityData element  4009  related to the financialAccount class in one embodiment. The securityData element includes a cusip element  4101 , which serves as a uniform security identifier for a particular security, and a symbol element  4102 , which identifies a unique security via a symbol. 
     Credit Bureau Reports 
     A credit bureau report data model can be used in various processes to determine whether particular financial products (e.g., loans and lines of credit) are available to a customer based on that customer&#39;s financial history. Examples of such processes include requesting credit approval, requesting a credit score, or requesting a fraud check (i.e., whether a customer has a record including fraud). These processes can be used to provide information to both individual customers (e.g., “What is my credit rating?”) and to organizations offering services or financial products (e.g., “How much risk is involved with this customer?”). For example, a phone company may desire to evaluate a phone service applicant&#39;s credit score. Once the phone company requests this information, the relevant information can be provided using a class implementation of the credit bureau report data model and its associated data elements (e.g., using “baseData,”“creditData,” and “relatedParty”). If the applicant&#39;s retrieved credit score is low and the risk associated with the applicant is high, the phone company may then, for example, require the customer to pay a deposit before phone service is provided. 
     In another example, an auto loan company may desire to evaluate an auto loan applicant&#39;s credit profile and request a credit report from a consumer credit bureau. As a result of a process using the credit bureau report data model, the auto loan company can acquire information such as payment histories for each of the applicant&#39;s credit accounts, as well as a credit score. Depending on the history of the applicant&#39;s various accounts (e.g., one Visa credit card account with no past due history, and another store card account with one three-month past due record), the auto loan company can determine, for example, the appropriate interest rate, down payment required, and payment plan. 
     Information relating to an individual&#39;s credit is typically collected in some form by institutions such as credit bureaus. Accordingly, in one embodiment, the credit bureau report data model can be used to match credit data provided by multiple credit bureaus and other organizations. It can also be used to support both historic data and analytical data. For example, in some embodiments credit information for a party is requested from external sources, including at least one credit bureau. When the requested credit information is received, the external sources, it is then stored in a credit bureau report record. The credit bureau report record may include a credit score and a credit history for the party. In this way, front end system may access a credit history for a party by retrieving static raw data from various back end systems, such as credit bureau systems, then analyzing and summarizing this raw data. The credit bureau report data model is easily extendible to support additional credit report-related processes. 
     Additional data that can be associated with the credit bureau report data model includes information relating to credit inquiries made by various organizations or individuals. For example, via an inquiry field, information relating to inquiry dates, types, and inquiring organizations can be indicated. 
     In some embodiments, information about credit-related fraudulent activities may be provided using the credit bureau report data model. For example, in some embodiments, information relating to an individual&#39;s fraudulent activities (e.g., reporting a credit card stolen to avoid paying charges) may be retrieved from court records, credit bureaus, etc., and may be provided using various data elements relating to fraud (e.g., fraud date, fraud type, comments, etc.). When provided with this type of comprehensive credit and fraud information, an entity inquiring into an applicant&#39;s credit can acquire complete information to make informed decisions, thereby reducing risk. 
       FIG. 42  illustrates the highest level data elements of a creditBureauReport class used to implement a credit bureau report data model in one embodiment. The creditBureauReport class inherits from the party class, the financialAccount class, the common class, a paymentMethod class, and the custom class. The highest level data elements of the creditBureauReport class include idData  4201 , baseData  4202 , creditData  4203 , creditReason  4204 , financialAccountData  4205 , fraudActivityData  4206 , inquiry  4207 , relatedParty  4208 , creditBureau  4209 , summaryData  4210 , and customData  4211 . 
       FIG. 43  illustrates the data elements of the baseData element of the creditBureauReport class in one embodiment. The baseData element includes asOfDate  4301 , combinedFlag  4302 , details  4303 , formatcode  4304 , and number  4305 . The asOfDate element  4301  refers to the date that the information was submitted or relates back to. The combinedFlag element  4302  indicates a combined report for more than one party (i.e., joint credit report). For example, as described above with respect to the application class, a husband and wife may share financial accounts. In such a case, a joint credit report is useful to describe their credit history. The details element  4303  is a field that holds the actual credit report. The formatCode element  4304  provides information related to the format of the report (e.g., simple credit report or complex credit report). The number element  4305  refers to the credit report number. 
       FIG. 44  illustrates the data elements of the creditData element of the creditBureauReport class in one embodiment. The creditData element includes riskModelCode  4401 , score  4402 , and statusCode  4403  elements. The riskModelCode element  4401  shows the credit risk associated with the report (e.g., high, low, etc.). The score element  4402  refers to the overall credit score associated with the report. The statusCode element  4403  refers to the status credit of the party. 
       FIG. 45  illustrates the data elements of the creditReason element of the creditBureauReport class in one embodiment. The creditReason element includes creditReason  4501 , which in turn has two additional elements, code  4502  and description  4503 . These two elements function to describe details associated with a credit score or rating. 
       FIG. 46  illustrates the data elements of the listOfFinancialAccountData element of the creditBureauReport class in one embodiment. The listOfFinancialAccountData section may contain credit historic data for all financial account information related to a customer&#39;s credit report and may have one or more financialAccountData elements  4601  for each individual financial account related to the credit report. In turn, each financialAccountData element  4601  will include data elements such as relatedFinancialAccount  4602  and pastDueData  4603 . Data elements associated with the pastDueData element include delinquenciesOver30Days  4604 , delinquenciesOver60Days  4605 , and delinquenciesOver90Days  4606  (i.e., divided into three categories based on past due length). 
       FIG. 47  illustrates the data elements of the listOfFraudActivityData element of the creditBureauReport class in one embodiment. The listOfFraudActivityData element may include a fraudActivityData element  4701  for each instance of fraud associated with a CreditBureauReport. In turn, each instance of fraud can be associated with its own elements including date  4702 , typeCode  4703 , and comment  4704 . The date element  4702  refers to the date on which the fraud activity happened. The typeCode element  4703  refers to a code indicating the type of fraud activity. The comment element  4704  is a field that holds comments related to the fraudulent activity (e.g., explaining the circumstances). 
       FIG. 48  illustrates the data elements of the listOfInquiry element of the creditBureauReport class in one embodiment. For each inquiry  4801  related to the CreditBureauReport, a relatedOrg element  4802  and a date element  4803  may be included. The relatedOrg element  4802  refers to the organization that made the inquiry. The date element  4803  refers to the date of the inquiry. 
       FIG. 49  illustrates the data elements of the summaryData element  4210  of the creditBureauReport class in one embodiment. The information in the summary data section may include both raw data provided from back end systems (e.g., credit bureaus) and analytical data reflecting aggregate information and summaries. The summaryData data elements include financialAccountsNeverPastDue  4901 , majorDerogatories  4902 , minorDerogatories  4903 , monthsPastOldestFinancialAccount  4904 , potentialRevolvingPaymentAmount  4905 , recentlyopenedFinancialAccounts  4906 , revolvingDebtToCreditRatio  4907 , totalFinancialAccounts  4908 , totalInquiries  4909 , and pastDueData  4910 . 
     The financialAccountsNeverPastDue element  4901  indicates the number of financial accounts/trade lines that were never past due. The majorDerogatories element  4902  indicates the number of major derogatories (e.g., failure to make payments, etc.) related to the CreditBureauReport. Similarly, the minorDerogatories element  4903  indicates the number of minor derogatories associated with the CreditBureauReport. 
     The monthsPastOldestFinancialAccount element  4904  indicates the number of months since the oldest financial account/trade line was opened. The potentialRevolvingPaymentAmount element  4905  indicates potential revolving payment options, providing an estimate of a maximum allowable account balance. The recentlyOpenedFinancialAccounts element  4906  indicates the number of financial accounts/trade lines recently opened (e.g., opened within sixty days) by the customer associated with the CreditBureauReport. The revolvingDebtToCreditRatio element  4907  indicates the revolving debt-to-credit ratio associated with the CreditBureauReport. The totalFinancialAccounts element  4908  indicates the total number of financial accounts/trade lines associated with the CreditBureauReport. The totallnquiries element  4909  indicates the total number of inquiries associated with the CreditBureauReport. The pastDueData element  4910  summarizes any past due data associated with the CreditBureauReport. 
     From the foregoing, it will be appreciated that although specific embodiments of the technology have been described herein for purposes of illustration, various modifications may be made without deviating from the spirit and scope of the invention. For example, the class definitions that have been described using XML schema can be equivalently described using other class definition tools, such as a C++ class. The classes described can be instantiated in memory and be initialized with information. Accordingly, the invention is not limited except by the appended claims.