Patent Application
20080162344
In order to support an end-to-end financial supply chain various computer systems located with various actors come into use. There are typically systems which are used by companies, and then there is are completely different systems used by the banks, who are involved in the financial transaction of moving money from one account to another. The various actors in the financial supply chain are using different systems which are sometimes incompatible due to the lack of standardized methods and schemes that defines the business semantic of common business objects in one or more different systems that are processing part of the financial value chain for the same financial transaction. This can hamper business activity. For example, the mappings between the two or more different systems may cause the lost of valuable information and sometimes the mappings create errors. If one actor in the financial supply chain introduce a new software, mappings and interface relationships with the other systems used by other actors need to be built or adapted between the systems, creating not only a time delay but also monetary expense.
In some countries, there is payment product called direct debits. In order to allow a creditor to draw money from an account of a debtor the debtor signs a direct debit mandate that must be kept by the creditor as documentation for the creditors right to draw money from the debtor's account via a direct debit payment order. Here, a mandate is the authorization or expression of consent given by the debtor to the creditor to allow the creditor to initiate collections for debiting the specific Debtor's account and to allow the Debtor bank to comply with such instructions A mandate may exist in paper-based form signed by the debtor or as an electronic document which is created and signed in a secure electronic manner. The mandate should be transmitted to the creditor bank with each direct debit or with a collection of direct debits. A debtor may request that the bank refund a payment made through a direct debit transaction, and the debtor can request his bank not to accept direct debits from a certain creditor or a debtor may even request that the bank completely prohibit the bank from debiting his account for any direct debit from any creditor. A direct debit transaction can be a one-off or a recurrent direct debit. A creditor with a signed mandate for a one-off direct debit is only allowed to debit the debtors account once. In addition a creditor may generate subsequent direct debit collections in line with the mandate for a recurrent direct debit. If a creditor does not present a collection under a given valid mandate for a given period of, for example, 18 months starting from the date of the latest collection presented, the creditor must cancel the mandate and is no longer allowed to initiate collections based on this canceled mandate. Such a new schema involving so many activities needs to be implemented in both the banking and customer/company enterprise resource planning (ERP) systems. However, an implementation of the above schema will show that a high degree of common functionality can be implemented to support both the accounts payable systems (ERP) of the creditor and the banking systems of the bank of the debtor.
Embodiments of the present invention include a method, a system, and an apparatus to implement a generic direct debit mandate software component. Further embodiments of the present invention provide for a generic direct debit mandate software component which can be used across business scenarios within both the banking and corporate ERP systems.
Embodiments of the present invention provide for a method to implement a software based service that can offer all the needed services for both corporate business scenarios and business scenarios within banks.
Embodiments of the present invention provide a system for reuse of functionality across business processes from both ERP systems and core banking applications. Embodiments of the present invention provide a system for enhanced functionality for all applications consuming the enterprise services offered for the direct debit mandate administration. Embodiments of the present invention provide a software component offering direct debit mandate enterprise services to other applications. Users may consume services from within other business processes and in-house applications. Embodiments of the present invention provide for major cost reduction for implementation and maintenance of the multiple software components due to the reuse of the generic software component for direct debit mandate administration.
Embodiments of the present invention may be used within various different business applications, e.g. enterprise resource planning applications and core banking applications, e.g., payment processing, loans processing and account processing.
Embodiments of the present invention provide for a cost reduction in the implementation and maintenance of the software components due to the reuse of the generic software component.
In an exemplary embodiment a leasing company and the bank of the customer of the leasing company both use the generic software component as provided herein. The leasing company (the creditor) wants to debit its customer once a month for the leasing rate. In order to do this it keeps information about the direct debit mandate signed by the customer in one or more business or process objects linked to the leasing contract with the customer. The bank of the leasing customer (the debtor) has the same business or process object in their core banking system linked to the account of the leasing customer. Whenever the leasing company triggers a direct debit to be debited to the account of their customer the bank servicing this account validates this transaction against the direct debit mandate information linked to the account within the core banking system. The generic implementation of the direct debit mandate business object allow both the system of the leasing company (ERP system) and the core banking system of the bank to use the same business object and common services offered by this business object. Thus, when information concerning direct debit mandates is sent between the leasing company and the bank, the information associated with the mandate business object is also sent and updated. Accordingly, a large mapping between the systems is not needed, as it would otherwise with other systems. A customer and a financial entity are both provided with less cost and more benefits since they can enjoy more services due to compatibility, and less time and cost consumption since no large mapping is needed.
Generally, a bank or lending entity and another entity, e.g., a company, will employ different software to process financial transactions. For example, a corporate entity will use an enterprise resource planning software. A bank oftentimes will develop its own software in-house to process payment transactions on behalf of customers However, each side's software will tend to have some overlapping functionality.
In embodiments of the present invention, a creditor may prepare a direct debit mandate and store/save/record/maintain the direct debit mandate (as yet unsigned) as a software object in a memory. The creditor then may send the prefilled direct debit mandate—or even, an unfilled in direct debit mandate—to a debtor for signature. The debtor then sends back the signed direct debit mandate to the creditor who updates the mandate business object with the information on the signature. The creditor can now initiate direct debiting of the debtor's bank account. When initiating a direct debit according to the signed mandate the creditor then send the direct debit mandate information to the creditor's bank to carry out debiting instructions. The creditor's bank then communicates with the debtors bank with the direct debit mandate to obtain the desired funds. The debtor's bank may contact the debtor for confirmation that such a debit is valid, or to notice the debtor that a certain amount of funds will be and/or has been withdrawn from the debtor's bank account.
In embodiments of the present invention, the direct debit mandate may be a “one-off,” i.e., one time occurrence, or recurring debiting of a debtor's account.
Examples of enterprise services 265 provided by the generic software component 260 include:
Create new mandate (signed or unsigned)
Print mandate (pdf, E-mail, paper, fax)
Change/amend mandate
Cancel/inactvate mandate
Read/search for mandate
Assign digital signature to mandate
Assign paper image of paper based mandate
Archive mandate
Block mandate
Delete mandate
Trigger correspondence to debtor about new mandates
Update status of mandate after a given period of inactivity
Validate direct debit payment order against mandate, etc.
At all reoccurring collections, the creditor's bank forwards the mandate information with the collection or payment order 430. For each collection, the debtor's bank validates the mandate information coming with the collection or payment order against the direct debit mandate linked to the account 440. The validation is done in order to see if the direct debit mandate is not locked or canceled by the debtor. Thus, the financial software must validate payment/collection against the direct debit mandate 445. Upon validating the information 442, if the information on the direct debit is found not valid, then an alert may be sent to the debtor, and/or the direct debit can be rejected by the debtors bank or some other correspondence/communication may be sent to any of the various parties involved 444. Also, the payment/collection is blocked from occurring 446. If the information is found valid, then the payment/collection occurs as mandated and ordered 448 and the amount ordered are debited to the debtors account.
The debtor may receive a pre-notification from the creditor company that the direct debit collection will occur again in 2 weeks 450. However, if the debtor is no longer receiving services from the creditor company, the debtor may wish to refuse further payments and ask his bank to block the direct debit mandate if the prenotified collection is executed 460. Thus, the financial software of the bank of the debtor must block the direct debit mandates either automatically, based on predefined rule(s), or manually (e.g., upon request) 465.
If, for example, the debtor's bank received a direct debit collection five days before the due date, a message or alert or correspondence may be manually or automatically sent (e g., letter, email, instant messaging, telephone call, facsimile, etc.) to the debtor to inform him that a direct debit is due to be debited on his account. Thus, the financial software of the debtors bank must trigger correspondence to the debtor or designated agent that a direct debit is due.
In embodiments of the present invention, an account holder (debtor is allowed to log on and view his direct debit mandates signed with various partners via his e-banking webpage (or other interface such as a computer system at the bank itself, etc.) The financial software involved allows for the reading the information of the direct debit mandates. In embodiments of the present invention, an account holder may view the direct debit collections due that have not been debited yet via his e-banking webpage (or other interface). The financial software involved allows for the reading of due direct debit collections. In embodiments of the present invention, a bank may have granted an account holder an installment loan. In order to pay the installments each month, the account holder may sign a direct debit mandate where the creditor is the bank, and thus, the bank can request and obtain the agreed payment each month. The financial software involved allows for the creation of a direct debit mandate for a loan debtor. In embodiments of the present invention, mandates may be made automatically invalid after a certain period, and/or after a certain period of not being used. The financial software involved allows for the status check of the direct debit mandate(s).
The network connecting the computer components of a system according to the present invention may include any type of interconnected communication system, which may implement any communications protocol, which may be secured by any security protocol. The corresponding network links may include telephone lines, DSL, cable networks, T1 or T3 lines, wireless network connections, or any other arrangement that implements the transmission and reception of network signals.
The computing device may implement any operating system, such as Windows or UNIX. Software may be written in any programming language, such as ABAP, C, C++, Java or Visual Basic. In various embodiments, application software embodying the functionality of the present invention may be deployed on a standalone machine or device, in a client/server arrangement or through a Web browser as a Web-based application or Web service, for example.
Several embodiments of the invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.
