EP1609088A2 - Method and device for the computer-implemented production and administration of contracts - Google Patents

Abstract

Method and apparatus for the computer implemented generation and administration of contracts between a supplier and one or more customers, wherein each contract consists of core data relating to a product which is the subject of the contract and one or more contractual components, the core data being stored in a first memory unit and the contractual components being stored in a second memory unit, and in order to draw up a contract a selection of core data is made and the contract is generated electronically of the selection made by automatically generating and depositing electronic references (links) to the selected core data and contractual components.

Description

 Method and device for computer-generated generation and management of contracts

The present invention relates to a method and a device for the computer-implemented management of financial processes and in particular for the generation and management of contracts, preferably contracts in connection with financial services.

According to the invention, a method with the features of claim 1 and an apparatus with the features of claim 11 are proposed.

Accordingly, contracts between a provider and one or more customers are generated and managed using a computer. The contracts to be generated and managed consist of core data for a contractual product and consist of one or more contract components, the core data being stored in a first storage unit and the contract components being stored in a second storage unit. To design a contract, a selection of core data is made and a selection of contract modules is made, and the contract is generated electronically on the basis of the selection made by automatic generation and storage of electronic references (links; so-called pointers) to the selected core data and contract modules. Thus, according to the invention, a so-called contract framework is provided, which helps to minimize the amount of data to be managed.

If a contract is concluded between a bank and a partner (customer, other bank) for a specific product (account, credit card, etc.), this is done on the basis of a stored contract template for the existing product with a selective possibility to overwrite individual agreements. In the framework of the contract framework, cross-product product creation and product management take place. Core data of the contract such as identification number, contractual product etc. as well as contract modules for central data management and assignment are generated and assigned when the system is set up. The contract modules form the basis for possible contracts that are compiled from core data and contract modules using the assignment entered. This assignment represents a product definition, so to speak. In the event of general changes to the general conditions, such as legal changes, a corresponding adjustment only takes place at one point and is then included centrally in all existing and / or future contracts for the given assignment. A bank can therefore create additional contract modules relatively easily and the maintenance effort for existing contracts is minimized. Reconstruction is possible by linking changes made in time. Future changes can also be made independently of the contract modules. Changes are pre-recorded for the entire system.

A globally unique identification ^¬ System (GUID = Global Unified ID) is performed by using an internal I- dentification a contract with all the ingredients, that can be clearly linked to external data, whereby the external data can then also change without a link or link being lost. Coupled with a deposit of several, preferably three, holiday calendars, this results in a system that can be linked worldwide, in which domestic and foreign bookings can be made in particular by means of only one system.

Procedural limits can be set by the bank itself.

If there is a release change, any existing customer-specific extensions are retained due to the defined interfaces. For this purpose, an extension is called up during testing.

The basis of the error concept according to the invention is a uniform representation of the errors originating from individual contract modules.

In an advantageous embodiment of the invention, a selection of the core data and a subsequent selection of the contract modules is carried out, with the basis of the selected core data, which contains information and rules relating to the contractual product, automatically checking the admissibility of the selection of individual contract modules. This measure according to the invention makes it possible to automatically check the admissibility of the composition of individual contract modules when the contract is being designed. In order for the In ^¬ entfallt wall to the further testing of a landscaped contract. In addition, the procedure according to the invention enables information and rules relating to the subject matter of the contract products, to carry out a central product configuration.

In a particularly advantageous embodiment of the invention, changes to the core data and / or the contract modules are carried out in the respective central storage unit. This measure according to the invention minimizes the maintenance outlay, since changes in individual contract modules (for example, changes due to changes in the law) do not have to be carried out in every individual contract of existence, but can take place centrally. A change in the core data and thus the properties of the contractual products can also be changed centrally with effect for all existing and future contracts. Advantageously, the centrally made changes to the core data and / or the contract modules are assigned time and / or date details which indicate when a change should become valid. In this way, upcoming changes (e.g. changes to the law from the following year) can be made in advance and will be implemented automatically from the defined later point in time.

In a further advantageous embodiment of the invention, changes in the core data and / or contract modules are recorded over time and stored by means of links. This measure allows changes to be tracked and a contract history to be created.

According to the invention, a so-called contract framework is thus provided, with which the interaction between the outside world, the contract to be concluded and the contractual product is made possible on the basis of so-called core data and contract components. Any contracts between contracting parties can be mapped. In front- In addition, the invention is used in the field of finance, ie the provider is preferably a financial service provider such as a bank, and the contractual products are financial products such as checking accounts, savings accounts, credit cards, check cards etc. An essential aspect of the invention is not to differentiate between different (product) sectors (such as giro, savings, credit etc.), but to allow a flexible structure through the central product configuration in the core data, which in particular also allows mixed forms, which is not possible with the current state of the art.

According to the invention, central functions are created by the contract framework for all contract modules and specializations (in the core data), such as time dependency, approval, change documents, direct input, control of the contract, jumps, product changes, copying contracts, central field modifications, authorization, blocking ,

According to the invention, the contract is clearly identified with an identification, in particular an identification number. This is preferably a globally unique identification (GUID, Global Unified ID).

The contract, which in the end consists of a link or link table, controls the "communication" with the product and ensures that all contract elements receive the properties defined in the product (i.e. in core data).

In particular, the contract receives the central attributes

Product type Product inversion Currency

status

Holiday calendar.

In an advantageous embodiment of the invention, three holiday calendars can be stored, which is particularly advantageous when calculating the value date of a booking. A (booking) day is considered a public holiday if it is stored as a public holiday in one of the calendars. The preferably three holiday calendars are the calendars, which are valid in the area of the organizational unit that manages the contract, the contracting party and the contract maintenance.

In a further advantageous embodiment of the invention, the contract module checks after contract generation whether the data taken over from the contractual product has been changed or not, and causes a link from product to contract module to be saved in a contract link table which contains the link between contract and contract module, if none Change was made, or a saving of the change as a new entry in a contract module table is prompted if a change has been made.

The invention extends of course to computer programs comprising program code means that are adapted auszufuhren when the computer program on a computer erfindungsgemaßes method and germedien computer readable Datentragermedien with stored thereon inventive computer programs and computer program products with such computer-readable Datentra ^¬. Further advantages and refinements of the invention result from the description and the accompanying drawing.

It goes without saying that the features mentioned above and those yet to be explained below can be used not only in the combination indicated in each case, but also in other combinations or on their own without departing from the scope of the present invention.

The invention is shown schematically in the drawing using an exemplary embodiment and is described in detail below with reference to the drawing.

FIG. 1 shows a target application landscape according to the invention in a schematic block diagram.

Figure 2 also shows a schematic block diagram of the components of the account management according to the invention.

FIG. 3 shows a schematic block diagram of the interaction of the components according to the invention within sales processing (where DispoOffice stands for Posting Control Office, DispoRules for Posting Control Rules, Posting Events for Posting Control Events or Posting Locks and DispoEvent Handler for Posting Lock Manager).

FIG. 4 shows a schematic block diagram of the structure of the posting lock office according to the invention.

FIG. 5 shows a schematic block diagram of an overview of the structure of the core application account management. FIG. 6 illustrates in a schematic block diagram the embedding of the contract framework according to the invention in a usage environment.

FIG. 7 illustrates in a schematic block diagram the structural structure of the contractual framework according to the invention.

Figure 8 illustrates in a schematic block diagram the interaction of the components product, contract and contract module.

Figure 9 is an illustration of the mapping structures.

FIG. 10 shows a data model according to the invention.

FIG. 11 shows a development workbench for developing the business data tool according to the invention in a schematic representation.

FIG. 12 illustrates the dialog flow in the business data tool according to the invention.

Figure 13 illustrates the direct entry process.

FIG. 14 illustrates the structure according to the invention oriented towards a contract module.

FIG. 15 shows a sequence sequence according to the invention when creating a contract.

The technical environment of the invention is first described below. The applicant of the present patent application has carried out in-depth market and competition analyzes in cooperation with international banks and consulting firms, the results of which are reflected in the applicant's current software solutions and in the further development projects. Based on this cooperation, a target application landscape for banks has been developed in recent years, which is based on the needs of the international financial markets. The individual applications of this software architecture represent solutions and integral components of the so-called e-busmess solution mySAP Banking. Basically, mySAP Banking can be divided into the areas of core banking, SEM for banks and CRM for banks.

Applications are information systems that solve a business primary task and are operational on their own. They hold the data and functions for solving the primary task, i.e. they are closely related activities. An application communicates via defined interfaces. An application is usually a buyable solution. Examples are the products Account Management, Profit Analyzer and Risk Analyzer.

In the following versions, applications are divided into core applications and accessory applications:

Core applications are the formative applications of the application landscape. Accessory applications are supplementary applications that expand the functional scope of core applications (also several). They perform special tasks (examples are limit determination and scoring models) and have their own investment cycle independent of the core applications. This will create a larger xibility guaranteed in the adaptation to changing business policy goals.

The application landscape of the e-busmess solution mySAP Banking describes the essential applications that are necessary for the operation of the banking business. The applications have a business-logical connection.

The "technical architecture" describes the link between applications using middleware. The "application architecture" describes the business content of individual applications and the logical interplay of individual application building systems. The blocks are called "components".

The SAP applications are based on a shell model: At the core is the solution for the international use of the software, in addition, country-specific solutions are offered. Customer-specific additions can be connected in a further shell based on BTEs (Business Transaction Events) or BADIs (Business Add-Ins) or use of BAPIs (Business Application Programming Interfaces).

The following requirements are placed on applications by financial institutions and banks:

• Customer-centered and sales channel-neutral support of the sales / service processes.

• Quick response to system requirements for the mapping of new products.

• Possibility of integrating new business processes.

• Processing of contracts independent of product lines as well as uniform inventory management. • Integration and consistency of internal and external accounting.

The following requirements are placed on the application landscape

• Flexible modernization of the application landscape over many years (depending on the investment cycle of the applications).

• Fast response options to changing business models (e.g. outsourcing, insourcing).

• Customer-specific expandability without modifying the standard solution.

• Support of different migration scenarios.

• Flexible integration into existing application landscapes at banks.

• Reduction of interface complexity through integrated processing within the SAP application landscape.

From this follows for the desired application landscape:

• The individual applications are interchangeable and expandable. In particular, individual applications must not be too extensive. In an integrated SAP system landscape, individual applications must be deactivated and third-party applications can be integrated.

• The bank decides on the desired range of standard functions by selecting the applications.

• Each application must be expandable in such a way that it can be integrated into customer-specific application landscapes. can be developed by SAP, by certified partners or by the customer himself.

Clear responsibility for applications

If one looks at central banking processes, various tasks and information needs can be derived from this. These different requirements are partially in conflict with each other and prevent the optimal design of individual solutions. So customer-centered process processing is the requirement of the sales and service organization for a solution. The cost-saving processing of contracts and accounts, however, is contract-oriented. Internal and external accounting in turn align the processes with legal and organizational conditions.

Applications communicate via public interfaces. Direct access to applications is not permitted. This ensures that data can be exchanged transparently between applications. A consistent database is guaranteed within an application. Unexpected risks due to unknown links and access can be minimized. This communication structure enables direct data exchange between applications via public interfaces or indirect data exchange via public interfaces and business middleware. For example, the Posting Control Office can communicate with Account Management via public interfaces; the data exchange can also take place via middleware with its own business intelligence. The middleware is a central element for realizing an application landscape. The middleware can perform two tasks:

• Technical communication (services)

• Business management

There are various solutions in the market for technical communication. They enable information to be exchanged between different databases in different formats.

The business management of business events requires a set of rules. This is defined as a business rule. Cross-application process knowledge is required to define the business rules.

Elements of the business rules are process objects that initiate the call of business objects in the individual applications. Example "contract creation": Here, for example, the business objects business partner, contract, card product are addressed. The depiction of front ends and back ends with the help of middleware is a common practice Therefore a clear conception of the process control is necessary for reinvestments in these areas.

This construction also allows a gradual migration with successive activation of new applications.

The interaction between applications and middleware is of strategic importance for SAP and is currently being actively calls. The question of performance plays an important role in the analysis of technical feasibility.

The structure of the target application landscape shows "key functional areas" with which the banking management solution fields can be mapped. Within such an "area" there can be several applications. Not shown is the area that contains applications that banks need for the processing of their secondary processes, such as human resources management, asset accounting, material management, etc.

The basis for this structure is the goal of defining application areas at a high level, which serves a specific main purpose. This allows applications to be derived and clear responsibilities to be defined. Redundant applications and functions can be avoided. The landscape is characterized by the following main tasks:

• Applications for customer-centered execution of sales and service processes.

• Applications for the implementation and control of trading processes.

• Applications for contract-centered, high-performance processing.

• Applications for legally and organizationally induced data calculation and preparation for bank management.

• Applications for the central provision of data that optimally support the other areas without being managed there redundantly. FIG. 1 shows a schematic diagram of a block diagram which represents a target application landscape for an account management according to the invention.

On the top level of the block diagram in FIG. 1, in the “Point of Sales & Services” field, there is the customer interface to the bank's sales and service point, such as the call center for telephone banking or a branch counter.

In the second level of the block diagram below, "CRM" stores data relating to the customer, operational data is data for existing customers, analytical data is data for new customer acquisition.

Finally, in the third level of the block diagram, contracts are concluded with customers under "Transaction Banking". These contracts concern accounts, loans, collateral, payment transactions, custody accounts, etc.

The bank control is located in the lowest fourth level.

Each bank communicates with the markets and requires interfaces for this. Value-adding transactions and business transactions are usually generated from this interface. They are of central importance for a bank because they also represent the appearance. Of course, these interfaces are diverse. The following can be mentioned as essential interfaces:

• Personalized two-way communication:

Branches, call centers, processing offices and trading rooms. Documentation and usually the confirmation of the communication results necessary. This form of communication is usually very personnel and cost intensive.

• Personalized one-way communication: self-service terminals, Internet, telephone. Here, a party acts through data entry and receives a system-generated result. In this case, the bank is not represented by employees, but by the system reaction.

• System-driven two-way communication: electronic trading systems, clearing systems, payment systems, market data acquisition, data exchange with credit agencies, reports to supervisory authorities. Here, bank employees only intervene manually in the event of malfunctions.

While payment systems have been continuously working on a system-driven data exchange for the past decades, an innovative change for customer service has only begun with the direct banks. The upheaval was accelerated by the Internet and, after the retail business (online banking), it now also covers the wholesale community (e.g. processing letters of credit) and trading (e.g. auctioning of emissions; increasing number of electronic trading places).

These new interfaces must be integrated into a bank's existing IT landscape. It is therefore sensible to decouple and encapsulate the sales channels in such a way that they can be quickly adapted to the rapidly changing trends. This fast response time can only be achieved if the front ends contain as little business logic as possible and are in a "sales channel neutral" application area. All customer-initiated business incidents should be recorded in the frontends. This is the only way to use the synergies and process optimizations of a modern software solution. Furthermore, the organizational decision to allow the recording of certain business incidents directly by the customer is easier to implement (e.g. the now customary recording of payment orders at the self-service terminal or via the Internet or cell phone, ordering travel payment means etc.).

There is a network between the forms of communication. For example, telephone users can be connected to a call center with one click if they have problems entering data. Against this background, it is all the more important to keep the data across all sales channels at a uniform level, so that all employees are informed about the activities and history of the customer.

Customer Relationship Management (CRM) encompasses the entire range of analyzes, activities and documentation in the context of customer contacts. This means that not only sales processes and the associated market cultivation are relevant, but also services during the term of the contract. For SAP, CRM is more than a database of marketing data. It includes operational processes with appropriate data storage. In current market solutions, many functions are available redundantly for each "channel". An immediate, sales channel-independent availability of business and sales functions is the goal of SAP in the context of CRM applications.

The following processes can be defined in operational CRM: Sales processes are focused on the acquisition of new business deals, on the one hand from the customer base, and on the other hand through the acquisition of new customers. Depending on the business area (retail / wholesale), product (payment transaction / asset or liability business or commission business) or customer group, this process is complex, risky and profitable.

Service processes include customer support during the contract life cycle. Key points include: blocking requests for cards, address changes, complaints.

The following customer-centered and sales channel-neutral solutions are required in this application area to map the processes named above:

The contract management supports the creation of applications and offers as well as the conclusion of the contract including correspondence and electronic files. The contract management shows customer-centered the contractual agreements between the bank and the customer. The contracts can be of any complexity. An example is a loan agreement with repayment by life insurance and a guarantee from a castle. If the contract data is called up, it contains a selection of processing-related information that is supplemented by sales and service-oriented data. These contracts can be processed via several applications, i.e. the relationships between individual contracts or partial contracts are documented over the entire term. Customer-centered sales and service processes have their "anchor" in the contracts of contract management.

Important processes: • Conclusion and documentation of the contractual and pre-contractual customer agreements.

• Content and time monitoring of contractual and pre-contractual conditions and events (e.g. payment requirements; lack of legitimation; prolongation dates).

Market-related configuration of products takes place in product management. This process takes place in coordination with the processing area of a bank. The presentation of products in this application area focuses on the market presentation of these products, i.e. on the variable characteristics that a customer can choose. The product must support the mass business in the retail business and ensure a uniform product portfolio and thus contract portfolio. The degrees of freedom of individual products are generally limited (e.g. a savings letter usually only has the nominal amount and the term as optional parameters). In contrast to the retail business, the wholesale business is characterized by a high degree of freedom within the product, since the contractual agreements must enable very individual characteristics.

Important services:

• Configuration of the product parameters

• Product calculation

Activities and contact management make it possible to record, monitor and control activities with the customer. Furthermore, all contacts with the customer are documented and can be evaluated according to various characteristics. The bank receives a "virtual" customer advisor who is available to all sales channels. For example, a complaint through the call center is also visible to the branch employees Information level guaranteed for all employees who are in contact with the customer. Customer activities via the Internet must be integrated accordingly in contact management.

The application area "Analytical CRM" comprises the analysis processes for exploiting business and customer potential and their transfer into operational implementation (e.g. marketing measures).

Analysis processes form an essential aspect of efficient customer relationship management. This includes processes such as cost information for controlling service, marketing and sales campaigns, customer-specific key figures for determining further customer potential, information about competitor products, etc. Primary tasks of analytical CRM are:

• Customer segmentation and profiling

• Campaign management

• Database marketing

Appropriate solutions support the bank in the planning and implementation of marketing measures, starting with the segmentation and profiling of customer bases through to the planning, implementation and control of marketing campaigns.

According to the invention, CRM is of strategic importance in order to be able to offer complete solution competence.

Applications to support trading activities are characterized by high product specializations. These solutions are characterized by special know-how and short investment cycles. Some of the existing systems for the Trading room back office processes still included. A clear cut makes it possible to process settlement and billing processes in a cost-reducing manner. Trading systems have frequent rudimentary risk controls. In banks, there is an increasing requirement that the control instruments of overall bank management are made available directly in the trade area, adding value.

Important processes in this area are:

• Product configuration for the retail business

• Contract management for the retail business

• Limit management for trade (exposure management)

According to the invention, no trading system is provided, but the trading activities are monitored.

The following initial situation exists in the "Transaction Banking" area: The globalization of the banking market expresses, among other things, the intention of market participants for efficient company sizes. To the desired Skalierungsund specialization effects take full advantage, has triebs- in recent years, partly in-house, but also partly operational over-reaching separation of Ver ^¬ and transaction banking emerged. Outsourcing solutions are an example of how the "transaction bank" is successful as an independent business model. However, even if the processing in the company remains the same, attempts are made to optimize the processing of customer transactions through automation and centralization.

Banks are currently operating in their application landscapes with a large number of product or division-specific systems. The transactions are costly and not scalable. Standardization of settlement processes and Extensive product line neutrality in the banking business are essential requirements for this application area. The configuration of processing processes should be accelerated and made more flexible through product configurations. The possibilities of the expandability of the software are of crucial importance, especially considering the long investment cycle of 15-20 years in this business area.

For SAP, this application area makes a significant strategic contribution to process optimization in the international banking world. The Transaction Banking application area contains the main components of payment transactions, account management (processing and inventory management), securities settlement and custody account management (processing and inventory management).

Account management is responsible for processing the legal portfolio in the sense of of money flows, i.e. it provides information about the bank's claims and liabilities to third parties. The inventory management of the account management is the source for account statements and Saidenmitteilungen. The balances and sales items are kept in currency, i.e. kept unrated. The inventory is the basis for external accounting, i.e. that the contract and sales data held here form the database for preparing the balance sheet.

In addition, the (partial) contracts are processed in Account Management. Partial contracts because a customer contract can be distributed across several processing applications due to its complexity. For example. In operational CRM, a product can consist of a "salary account with credit card and travel insurance". While the salary account is managed in account management, the card is processed by a provider and travel insurance at a partner. The processing functionality means that automated prolongations or contract settlements take place. For operational CRM, this means that the current contract status must be known from the processing inventory.

Only legally valid contracts are kept in account management, i.e. Simulation transactions, offers and applications are outside the operational CRM.

Payment systems are traditionally country-specific solutions. The payment transaction system takes over the formal checking and, if necessary, the consolidation and distribution of sales within the routes and formats used by the bank (internal and external routing).

Payment systems traditionally work in the so-called batch process. In addition, dialog entry of payment orders is necessary, which can trigger immediate real-time booking in Account Management (additional application in payment transactions). Highly perfor- mance-based communication must be ensured between payment systems and account management.

In principle, within the scope of the present invention, the administration and execution of standing orders is an additional application in payment transactions (payment order and standing order are within the account management). However, it is also conceivable to do this as a supplementary component within Account Management (e.g. rebooking within Account Management).

The Transaction Banking application area contains, in addition to the solutions described above for the money side, solutions for securities transactions and derivative financial transactions. It can therefore be assumed that in As a rule, several inventory management systems are located in this application area. The peculiarity of stucco management (securities settlements / custody account management) is that in the area of customer business it is an inventory management that does not affect the balance sheet.

The business partner solution is a central application for storing and managing all customer information. This solution is very closely linked to the solutions for operational and analytical CRM. Due to the process link, the business partner is maintained as part of these processes. The business partner data represent an essential intangible asset for ede Bank, the value of which is determined by the quality of the data.

The business partner application merges the customer data of a bank across all applications. The most important data are:

• Name and address of the business partner

• Additional data depending on the business partner type (e.g. date of birth; legal form) for all application areas (e.g. industry key for marketing selections or reporting)

• Relationships (e.g. borrower unit; group structures)

• Roll

• Identification data

• Credit rating data / data from credit agencies / scoring results / marketing clusters

• Budget statement data or balance sheet analysis

• Total commitments Relationships between business partners can be linked in a variety of ways. Functions are available for creating borrower and risk units.

Customers appear in defined roles towards a bank (e.g. account holder, borrower, guarantor). For this reason, the business partner application has the role of a customer as a supporting component.

The application area "Central Services" contains solutions that support the banking business of the other areas.

• Collateral management

• Output and input management / correspondence

• Market data, securities master data, info services

• Administrative services: authorizations, organizational units

Collateral management is of particular importance due to the Basel decisions on credit risk coverage. By differentiating collateral, a bank can optimize the capital backing and thus reduce borrowing costs. Furthermore, knowledge of the collateral and its value date is a source for the acquisition of new creations. Collateral is usually recorded when the contract is initiated and concluded and is initiated from operational CRM. Collateral is released as part of the contract processing.

The management of collateral comprises firstly Safe ^¬ units that takes the bank and on the other collateral that the Bank itself. There is currently hardly any solution on the market for this second aspect. But need a bank's activities in the field of derivatives also the documentation and control of self-provided collateral.

Collateral management is an important part of the overall solution.

The output management / outgoing correspondence application is a solution for optimal communication with the customer. Different media such as mail, fax or email are required. There may be dependencies between the media. Furthermore, legal information deadlines must be observed (e.g. written account closure).

Besides the choice of output media is a high functionali ^¬ did in the control and treatment of paper-based correspondence necessary. The keywords here are: central print preparation; Forms and postage optimization.

The invention supports the correspondence-oriented data selection and preparation. Further processing in a printing and shipping line is carried out by special providers.

For input management / emgehende correspondence heard the "Electronic File", and the general linking of documents to the objects contract, business Saves ^¬ ner, etc. The input management is located as a central service in the operational CRM.

Here is solutions that len within a bank information for multiple applications at your disposal stel ^¬.

The "Administrative Services" services are used for the proper organization of banking operations. The existing system landscapes have historically grown at most banks. The operative systems play a central role here and often supply downstream systems with pre-calculated results. This often results in different results and a complicated reconciliation and coordination process. The timely basis for decision-making can no longer be created.

The requirements for bank management are therefore single source of the database and method consistency across all evaluation methods. In order to achieve the goal of coordinating data and methods, the systems of a bank have to be organized differently than before. In particular, there should be a clear cut between the operational systems and the applications of overall bank management. This relieves the operational systems of the downstream processes of the overall bank management and at the same time centralizes the processes. The data required by the operational systems is made available at a data interface.

Bank management affects not only individual institutions, but entire groups. Uniformity and transparency of the methods as well as their representations are of great benefit especially for the group-wide control.

According to the invention, the following specialist areas are integrated into overall bank control:

• accounting

• Profitability / controlling

• Active / passive control

• Risk controlling o Market risk / internal models o Credit / counterparty risk o Counterparty risk o Country risk

• Notification

• Limit management (analytical)

Transaction banking has the following central tasks:

• Control of money and stucco traffic

• Processing the contract portfolio

• Sales management and management of the legal inventory on the cash and stucco side)

The scope of the transaction banking solution is described below.

In order to embed the functionality of transaction banking in the overall context of the application landscape, the following aspects are dealt with first:

• Processing options

• Leading data storage

• Product configuration and financial terms

editing options

Transaction banking, as a separate application area, has the need to be processed directly. The reasons for this can be:

• Planning and limit management for quality assurance of the portfolio.

• Complaint processing, such as Gebuhrenkorrektur.

• Bestandsfuhrungsprozesse, such as processing and downs ^¬ mood of one-time accounts. • Corrective measures due to incorrect or missing data import (eg value adjustments, booking corrections).

Traditionally one speaks of the account management as a supplement to the customer advisor. The invention is designed in such a way that the implementation of the account manager is possible. This role comprises the following two fields of work:

On the one hand, there are activities that have a direct external effect on the customer (e.g. limit reduction) and, on the other hand, activities that only affect the inventory "without customer contact" (e.g. one-time processing, data corrections).

There are two types of processing layers in transaction banking:

• Basic Maintenance Interface (BMI)

• Processing office (Account Management Office / AMO)

The Basic Main tenance Interface is a surface for processing individual functions.

This surface allows manual interventions in the otherwise largely automated processing. All functions in this area thus have a surface. An approval process ensures revision-compliant processing. A release tool that is integrated in the system in the individual applications is suitable for this.

This surface is provided by default and the authorization profiles for these workplaces can be defined by the user as roles, so that each user has a menu that exactly corresponds to his system requirements. These surfaces do not take into account customer organizational processes and processing optimizations.

The processing office (Account Management Office / AMO) ensures the process-controlled, i.e. workflow-supported processing of business incidents. There are various role-based forms within the office.

The control is supported by customer-specific settings of the SAP workflow and the associated release procedure (4 to 8 eyes principle). In comparison to the Basic Maintenance Interface, these offices have their own data storage (e.g. disposition orders). Crucial for an office integration is cross-application access to functions and data for the processing of business incidents. Furthermore, the results of the offline activities are to be transmitted to the central contact management so that a fully customer-centered view is possible across the bank.

Today there are often processes in processing that do not belong in this area (e.g. contract opening by post).

In addition, market studies show that the aim of banks is to streamline many back office processes by 70-80% simply by shifting them to the customer, as is already possible in internet banking (e.g. opening a contract) , Because processing is only as efficient as possible if the bank customer can initiate business transactions such as a card block or carry out the payment order dispatching himself.

Leading data storage In each application landscape there can only be one "master" for the data, to which other applications can directly access or receive periodic updates.

The master for the partial contracts that are to be processed lies in account management, i.e. the valid contract dates and conditions are stored there.

The same applies to sales and balances. For this reason, data is provided for the account statements and for a data warehouse.

The extent to which applications must keep data redundant is largely determined by the performance requirements and depends on the customer-specific situation.

Product configuration and financial terms

product configuration

As shown in the target application landscape, product configuration is a central topic of a modern, future-oriented solution. The product configuration takes place under three different aspects:

• The product configuration in operational CRM. Here the product configuration is based on marketing and sales needs.

• The illustration of the processing product with all ^¬ from development-related control parameters within the transaction banking / account management.

A product compared to the market can be divided into several sub-products for processing. • The configuration of products for bank management. These products generally have a different granularity than the settlement products. The data budget is also geared to the evaluation needs and not to the processing requirements.

In the three main processes of banking, the product is different, with one exception: "The financial terms of the product". For this reason, the financial terms are shown in addition.

The product configuration ultimately spans all three application areas. A comprehensive coordination between the application areas is necessary as part of a new product implementation. The care of the products takes place in each area for itself:

In transaction banking, product maintenance takes place using Customizing. Authorization and release are secured using the SAP transport procedure.

The connection between Operative CRM and Transaction Banking takes place when a specific contract is created with a customer via a public interface (BAPI). The following are given in the interface:

• the customer

• the product ID

• and the individual terms of the contract.

The connection to the processing (part) product is established by the product ID.

financial conditions The financial conditions are the basis for the interest and fee calculations. As a result, they have a special meaning and must be available in every application area. Access as part of inventory management is critical. In order to guarantee the uniformity of the conditions beyond the limits of individual application areas, SAP provides the financial conditions of the account management via BAPIs to all other applications.

Figure 2 uses a block diagram to illustrate the components of "Account Management". "Account Management" has a structure that is neutral to the product lines. The development initially focuses on payment transaction products and services as well as passive and active products in retail banking.

The contract component is designed as a framework. It is therefore conceivable to use it as a central service for all applications in the target application landscape.

It is conceivable that the contract and its framework can be used in the future as a central service for all applications in the target application landscape.

The contract manages all transaction-relevant master data in the account management via contract modules. Contracts use products as a template. The contract is aimed at extremely high-performance processing in bulk business.

Released contracts are usually passed on from the feeder systems to contract management via an interface (BAPI). During the contract period, however, it can be expected that directly from the trans saction Banking accessed the contract and changed data. Special contracts such as contracts for one-time accounts are created directly in Account Management. The contract knows the released and not released condition.

There can only be one "master" for all contract data in an application landscape. This "master" for the processing data lies in the account management. In addition, the processing of contracts is largely automated. This means that you know the current contract status (e.g. after prolongations). The contract data are made available at interfaces.

To understand it is noted that there are of course also ^¬ order data Ver managed in other applications and be guided there as a "master" (eg Schufa indicator Verfugungsberechtigung). The central anchor for leading together all the data is in the operational CRM.

Important processes in account management are:

Creating, changing, prolonging, informed, canceling and dissolving contracts. Appropriate postings are also triggered.

Two types of contracts are supported:

• Account contracts

• Card contracts (see below)

The support of other contracting parties is of course possible.

sales administration The essential value creation of account management lies in the mapping and processing of transaction data. The solution must be high-performing and incur low costs. Further requirements for the solution are real-time processing and 7 x 24 hour availability.

The sales management posts the individual sales in real time and controls a flexible balance update. The movements are shown on the account. Individual sales are payment items (half-sales), the basis of which are payment orders on the one hand and internal settlements on the other (e.g. interest charges). In addition, cash flows can be calculated and processed. Account management has an interface for accepting payment items (BAPI).

Sales management has no open item management with corresponding line item clearing. Balance-based payment monitoring is conceivable, e.g. controls the receipt of funds in the course of a time deposit or the payment in installments for loans.

Incoming payment items are checked for blocks and limits as part of material planning. A set of rules (Posting Control Rules) flexibly controls the reaction of the system based on specified parameters. For example, customer-specific, it can be determined whether sales should be scheduled or rejected directly.

System reactions are:

Booking, re-scheduling, post-processing, return, rejection, one-time booking.

The individual turnover is also the basis for the general ledger handover. The data is also used to create a bank statement. The sales update is true and without valuations. Orders describe the actions that the account management should carry out immediately or in the future. This means that orders can be monitored in an appointment file. These orders can change one or more objects.

Account management processes orders. Examples are "contract cancellation" and "set block". These orders are initiated from the outside via interfaces or internally by the application itself (e.g. term monitoring for renewal cards).

In addition, central applications, such as the management of orders and payment orders, are provided as additional functions (cf. previous versions).

The card solution uses the same components of product configurator, contract and financial terms as account management. Thus, the administration of cards is a specialization of the general contract. The integration of card management into account management is necessary because there are close links between cards and accounts (e.g. EC card, debit card). In particular, SAP wants to keep the option open to process credit card accounts on the revenue side in the medium term.

The card administration must be a solution that can be used optionally by the customer, ie the card management must be switched off within the account management. Furthermore, the card management should be expandable in the medium term so that it can be used as a standalone solution if there is a corresponding need on the market. According to today's experience, there is a need for an account management system, including and exclusive of one Card administration. There are no requests for card administration alone.

The account management has a central financial statement administration for periodic work (eg end-of-day processing). The bank is given the greatest possible flexibility when planning jobs. Periodic work summarizes the functions that have to be carried out repeatedly on a certain date. These include the closing work cash concentration, account closing, interest compensation, account statement, the processing of orders, the daily closing including the updating of the bookers and reporting. Before the final work is carried out, the booking cut is made. Then all bookings are made with the following current date.

External job control systems can also be integrated.

The Posting Lock Manager is responsible for temporary booking locks, i.e. he sets locks that are triggered by business incidents (posting lock events) and removes them after the underlying event has expired. Locks that are defined a priori on the product are not part of this component.

Figure 3 shows a block diagram to illustrate the interaction within the sales processing with the participation of the so-called "Posting Lock Manager", and Figure 4 shows a schematic block diagram of the structure of the so-called "Posting Control Office".

The Posting Lock Manager accepts and determines Posting Lock Events from various input channels (back office, call center or counter systems and credit agencies) - according to its rules - the response of the system. The solution runs in operational operations (receiving and processing events) largely without manual intervention. In account management, possible forms of blocking procedures are the contract blocking (the contract as a whole and the blocking of partial functions), the blocking of cards in the portfolio as well as checks and other payment transaction forms. The central business partner block, which extends across all customer accounts, can be set on the business partner.

If, for example, a business partner registers a comparison, the Posting Lock Manager distributes the corresponding locks. So this rule can e.g. lead to an overdraft and direct debit block on all accounts and a block on all cards of the business partner concerned. This set of rules can be expanded to meet customer requirements.

Due to the primary task of account management to manage the legal inventory, flexible reporting is available. There are also numerous lists, such as Overdraft, balance and turnover lists. It is also possible to create lists for account and check blocks and to generate reconciliation balance lists for comparing payment transaction balances.

The definition of further reports is flexible.

Accessory applications for account management from the perspective of the application landscape are:

• Posting control office

• Dynamic limit determination

• Dunning / delayed payment As already mentioned in the introduction, accessory applications complement or support the function or task of one or more core applications.

The Posting Control Office is an additional application for account management that is used to dispose of payment items for which a block or an unauthorized overdraft was found when an attempt was made to post.

Payment items that encounter booking obstacles (blocks) and accounts in which an unauthorized overdraft occurs are scheduled according to a set of rules (Posting Control Rules). This customer-specific, adjustable set of rules is managed in Account Management. If necessary, information about payment items that are not explicitly rejected in response to the Posting Control Rules is sent to the Posting Control Office by means of a posting control order, where their further processing (disposition) takes place either automatically or manually. Automatic disposition (repetitor) includes the automatic resubmission of payment items for posting to Account Management. Payment items for which there are only temporary obstacles to posting (e.g. limit problems) can be scheduled using the repetitor without manual intervention.

The duration and frequency of the resubmission as well as the final reaction (e.g. rejection) in the event of unresolved or newly emerging booking obstacles can be set.

Manual processing of payment items to be scheduled takes place on the Posting Control Desktop. In this partial solution, role-based design and usability are of central importance. The dispatcher is accessed through based on planning-relevant data in its decision to either process payment items finally (actions such as posting, rejecting, etc.) or transferring them to automatic planning.

Dynamic limit determination is a solution that is particularly necessary in automated mass business. This is an accessory application for account management that enables the individual bank to automatically set limits for the customer based on defined rules and input parameters.

The dynamic limit determination is programmed by the customer or in customer projects according to individual needs. The limit determination communicates with inventory management, the business partner and the operational CRM.

This accessory application is responsible for extrajudicial dunning processes.

FIG. 5 shows a summary of the structure of the core application Account Management using a schematic block diagram.

The invention will now be described in more detail with reference to FIGS. 6 to 15.

The link table stores the assignment between the contract and the contract modules. Any number of assignments and the function of the assignment can be saved between the contract and the contract modules. The assignments are time-dependent. Release and change documents are also saved here. Various attributes are key fields for the link identification and time stamp, the contract identification, the name of the Contract module, identification for the module table etc.

In connection with this invention, the “contract module” is to be understood as the sum of the code of a contract module, that is to say the coding which the contract module data and its process logic represent, for example, in dialog or store in the contract module table. The contract module table is / are the database table (s) of the contract module (naturally does not apply to contract modules without their own database table). Contract building data is the data of a contract module that is assigned to a contract. The data is normally stored in one row of the contract module table but also contract modules in which the data takes up several lines, and other contract modules do not have a contract module table at all, but contract module data do.

In contrast to the state of the art, in which the content of its attributes is saved individually for the design of a contract for each contract module (i.e. in the terminology at hand, a new data record is added to the relevant contract module table for each contract module concerned), which results in a large amount leads to redundant and redundant data, according to the invention, no new data record is added to the contract module table, provided that a contract module does not change the data of the contractual product. This procedure is based on the knowledge that the product-specific attributes are generally adopted unchanged in the contract in the daily mass business. The database table is advantageously buffered, since access is then significantly improved and is carried out more quickly.

Each contract component is in turn encapsulated in its own development class, which leads to decoupling.

According to the invention, the contract modules in account management can be used across product types, so that fields that belong to a common (business) topic are grouped into a contract module.

According to the invention, a further distinction is made between generic contract modules and product type-specific contract modules (account contract modules, card contract modules, card community contract modules, account pool contract modules, etc.). In the generic contract modules, properties are of a general nature, such as the connection of the business partner, the contract conditions, limits, payment details, notice periods, correspondence requirements, related contracts, contract purpose, contract name and the like. included, while attributes such as bank statement, account closure, general ledger update, posting blocks, debit orders, balance confirmation, basic account data, alias names etc. are stored for the product type-specific contract modules.

In the application architecture according to the invention there is an entity "Link: product module" or in short "product link" (cf. FIG. 10). This entity belongs to the “contract” package and not to the separate product configurator 10. The function of the product link is to create an assignment between a product (or a product version) and contract modules and to enable contract modules that do not make changes to the specifications of the product to not have to make any additional entries in the associated contract module table.

In a separate link table, pointers (pointers) to the contract module data belonging to a product version are stored (i.e. a link between the product and an associated contract module and its attributes). When a contract is created, these pointers are transferred to the contract module so that they can be saved in the contract module link table. The contract then points to the same contract module data as the product. There are thus product links between the product and the contract modules and contract links between the contract and the contract modules.

When changing the product version, certain properties of the product are changed, which can affect one or more contract modules. Effects on the contract modules in turn affect one or more contracts. The corresponding contracts, which are affected by the changes in the product, are selected by specifying which product it is and the associated links are adjusted.

According to the invention, the reusability of the contract modules is thus made possible. In addition, the invention enables the creation of "contracts via contracts", ie joint contracts such as card associations and the like can be managed as one contract. Contracts and contract modules are application data (in contrast to the products and product attributes, which are so-called customization data) that cannot be transported. The table of links between the product and the contract module data is therefore an application table, since no contract module data can be created when you create or configure a product, and therefore no link can be created between the product and the contract module data.

According to the invention, when a contract is created by a contract module, the product is not called directly, but instead the product link is called up and the contract module is linked to contract module data. When the contract is saved, the contract module checks whether the data transferred from the product has been changed. If this is the case, the changed data is saved as a new entry in the contract module table. If the data has not been changed, however, only the link (product to contract module data) is saved in the contract link table (contract to contract module data), with the note that the contract is not the "owner" of the contract module data. The contract module table remains unchanged.

The result of this procedure according to the invention is that an entry exists in the contract module table, on which both the product version and a large number of contracts show. In addition, there are some other entries, each of which a contract points to, namely when a contract has changed the specifications of the product. It is noted in the contract ^{link table} whether the contract is the "owner" of the contract module data (ie the data individually belongs to the contract) or not (ie the data belongs to the contract Product, the contract has only "inherited" them - through linkage.

When you first create a contract for a product or a product version, the product link table is still empty. If the product link notices that it has not yet saved any links to this product or to this product version, it asks the contract modules concerned to get their "default values" from the associated product, to save them and to return a link to the stored data The links or links to the entries - the product link remembers in its own lmktable .. Then, upon request, it gives the links to the individual contract modules as described.

Changing a contract is an individual change, i.e. Contract module data will be changed with a new entry in the corresponding contract structure table and a new link in the contract link table.

When archiving contracts, the peculiarity is that the contract and the links belonging to the contract are used to archive those contract module data for which the contract is "owner". Those contract module data for which it is not "owner" are not archived because other contracts can be linked to this contract construction data.

When creating a contract (cf. FIG. 15), the contract calls the product link with "with". If the product link determines that it still has no links to this product version, it calls the relevant contract modules with "SetDefault". The contract modules then get their default values from the product with "GetDefault", save them and give them the link back to the product link. In the further course, the individual contract modules get their links with "Get" from the product link. This means that the "SetDefault" and "GetDefault" processes shown in bold in FIG. 15 only appear when a contract is first created for a specific product or a certain product version.

The abbreviations used in FIGS. 11 to 14 have the following meaning:

ISSTA initialization

Read ISDAT data from the DB

ISDST distribute data to participating application

FCODE Edit your own function code

XCHNG check whether data has been changed

DCHCK checks before saving

DSAVB collect data when the application is owned

DTAKE remember data in the whole memory

Complete DSAVC data (pull internal number)

Save DSAVE data in DB

Initialize DLVE1 current memory

Initialize DLVE2 overall memory

The invention is illustrated below with the aid of an exemplary embodiment for a fictitious product called “easy” and a contract module “general ledger data”:

Creation of the product "easy"

The "easy" product (version 1) is created and tested in the customer's customizing system.

Finally, it is transported to the productive system.

Creation of the first contract

The first contract (No. 1) for the product "easy" is created The contract tells the product link that it should prepare for the product "easy" (call the Init API)

The product link determines that there are no links to the "easy" product. It now calls up all contract modules with set_defaults-API, including the general ledger data. The general ledger data now fetches its default values from the "easy" product, save them and generate a key for this (HB_1). They return the key to the product link. The product link stores all links between the "easy" product and the contract modules.

Now the contract modules call up the product link in order to get a link to their data. The "General ledger data" contract module calls up the product link with Get_API and receives the HB_1 key.

When the contract is saved (assuming that the general ledger data has not been changed), the "General ledger data" contract module transfers its key HB_1 to the contract link table and tells it that it is not the contract (but the product) that is the owner of the data.

The database tables now have the following entries (simplified):

Contract table

Contract module general ledger data

General ledger attraction key bute

HB 1

product link

Creation of standard contracts

Now contracts 2 to 4 are created. You all do not change the general ledger data specified by the product (normal case)

The contract tells the product link that it should prepare for the product "easy" (call the Init API)

The product link gets the links of this product in its buffer

Now the contract modules call up the product link in order to get a link to their data. The "General ledger data" contract module therefore calls up the product link with Get API and receives the HB 1 key.

When the contract is saved, the contract block "General ledger data" gives its key HB_1 to the contract link table and tells it that it is not the contract but the product owner of the data. The database tables now have the following entries (simplified):

Vertra blinking table

Contract module General ledger data General ledger key Attrib ssel ute

HB 1

Creation of an individual contract

Contract 5 is created. He changes the general ledger data individually (exceptional case) The contract tells the product link that it should prepare for the product "easy" (call the Init API)

The product link gets the links of this product in its buffer

Now the contract modules call up the product link in order to get a link to their data. The "General ledger data" contract module calls up the product link with Get_API and receives the HB_1 key.

The user now changes the general ledger data displayed and saves.

The "General ledger data" contract module saves the changed data under a new key (HB_2) and informs the contract link table of the new key and tells it that the contract is the individual owner of this data

The database tables now have the following entries (club ^¬ fanned):

Contract table

Contract block of book data

Claims

claims

1.Procedure for the computer-implemented generation and management of contracts between a provider and one or more customers, whereby each contract consists of core data for a contractual product and one or more contract modules, which core data are stored in a first storage unit and which contract modules in a second Storage unit are stored, and where a selection of core data is made and a selection of contract modules is made to design a contract and the contract based on the selection made electronically by automatically generating and storing electronic references (links) to the selected core data and contract modules is generated.

2. The method according to claim 1, in which a selection of the core data and then a selection of the contract modules is carried out, wherein on the basis of the selected core data that contains information and rules relating to the contractual product, a check of the admissibility of the selection of individual contract modules is automated he follows.

3. The method of claim 1 or 2, wherein the first storage unit and the second storage unit are identical.

4. The method according to any one of claims 1 to 3, in which a central identification number is assigned to each stored contract, which allows a link to data external to the system.

5. The method of claim 5, wherein the central identification number is unique worldwide.

6. The method according to any one of claims 1 to 5, are carried out in the cross-contract changes to the core data and / or the contract modules in the respective central storage unit.

7. The method according to any one of the preceding claims, in which contract components are predefined.

8. The method according to claim 6, in which changes in the core data and / or contract modules are recorded in time and stored by links.

9. Method according to one of the preceding claims, in which the provider is a financial service provider and the contractual products are financial products.

10. The method according to claim 1, wherein the contract module after contract generation checks whether the data transferred from the contractual product has been changed or not, and - if no change has been made - storing a link between the product and the contract module in a contract link table that the Link between contract and contract module contains, prompted, or - if a change was made - prompted to save the change as a new entry in a contract module table.

11.Device for computer-implemented generation and management of contracts between a provider and one or more customers, each contract consisting of core data for a contractual product and one or more contract modules, with a first storage unit for storing the core data and a second storage unit for storing the contract modules, with a device for selecting core data and for selecting contract modules to form a contract, and with a generating device for electronic generation by automatic generation and storage in a link table of electronic references (links) to the selected core data and contract elements.

12. The apparatus of claim 11, in which a selection of the core data and then a selection of the contract modules is carried out, whereby on the basis of the selected core data, which contain information and rules relating to the contractual product, a verification device automatically checks the admissibility of the Individual contract modules are selected.

13. The apparatus of claim 11 or 12, in which the first storage unit and the second storage unit are identical.

14. Device according to one of claims 11 to 13, in which each stored contract is assigned a central identification number which allows a link to external data.

15. The apparatus of claim 14, in which the central identification number is unique worldwide.

16. The device as claimed in one of claims 11 to 15, in which cross-contract changes to the core data and / or the contract modules are carried out in the respective central storage unit.

17. The device according to one of claims 11 to 16, in the contract modules are predefined.

18. The apparatus of claim 16, in which the changes in the core data and / or contract blocks are recorded in time and stored by links.

19. Device according to one of claims 11 to 17, in which the provider is a financial service provider and the contractual products are financial products.

20. Apparatus according to claim 11, in which the contract module checks when a contract is generated, whether the data taken over from the contractual product has been changed or not, and - if no change has been made - storing a link between the product and contract module in a contract link table which contains the link between the contract and the contract module, or - if a change has been made - the change is saved as a new entry in a contract module table.

21. Computer program product with a computer-readable medium and a computer program stored on the computer-readable medium with program code means which are suitable for executing a method according to one of claims 1 to 10 when the computer program runs on a computer.

22. Computer program with program code means which are suitable for executing a method according to one of claims 1 to 10 when the computer program runs on a computer.