Mutual fund customer identification

A computer-assisted method is provided for verifying identifying data of a customer of a financial institution. The method includes receiving the identifying data of the customer in a customer processing system of a customer identification program; applying at least one of a customer matrix or a scenario matrix to the customer identifying data for determining applicability of the customer identification program to the customer; searching at least one record of the customer identifying data with at least one government list function; and, communicating at least one record of the customer identifying data to at least one verification vendor.

FIELD OF THE INVENTION

The present invention generally relates to collecting, analyzing and other processing of data to verify the identities of customers of a financial institution such as a mutual fund.

BACKGROUND

Historically, mutual funds have not possessed specific information about the identities of their individual customers, nor have they verified the identities of their customers. Mutual funds typically do not interact directly with their customers, often instead employing transfer agents to receive, review and process documents such as applications for new accounts. It can be appreciated that this way of doing business in the financial industry has created a high degree of anonymity between mutual funds and their customers.

In association with enactment of the USA PATRIOT Act (“Patriot Act”), the Treasury Department and the Securities and Exchange Commission were directed to develop rules and regulations for implementing customer identification programs (“UP”) to address the need to verify the identities of customers of financial institutions such as mutual funds. To satisfy the requirements of the Patriot Act, mutual funds and other financial entities have been mandated to establish and execute such CIPs in their business operations. A properly administered CIP requires financial institutions to undertake “reasonable procedures” for verifying the identities of their customers, to maintain customer verification records, and to compare customer information against certain government lists (e.g., government lists of known terrorists). It can be seen that enactment of the Patriot Act has forced a fundamental change in the nature of the relationship between mutual funds and their customers and how mutual funds must conduct business.

In view of the compliance issues arising from this regulatory environment, effective and efficient processes are needed for obtaining, processing and storing identifying information for customers of financial institutions, including mutual funds.

DESCRIPTION

As applied herein, the term “CIP” represents “Customer Identification Program” and may be employed to identify a variety of methods, systems, apparatus and/or computer products or computer-readable media provided in accordance with various embodiments of the present invention. A CIP may be employed to obtain, analyze, and/or store identifying data associated with various customers of a financial institution with respect to requirements of the Patriot Act, for example.

As used herein, the term “financial institution” is defined in accordance with the Patriot Act and all of its applicable amendments, revisions, and provisions. A “financial institution” may also be any entity that performs compliance activities in accordance with the Patriot Act, either by itself or through cooperation with another entity (e.g., a third party service provider). A “mutual fund” is one example of a financial institution, and the term “mutual fund” or “fund” may be employed illustratively at times herein to represent a “financial institution” in a generic sense.

As used herein, the term “customer” may be any person or entity for whom identifying data is collected and processed in accordance with various embodiments of the invention. A “customer” may be the person that opens an account in a mutual fund, for example, or a new registered owner of a shareholder account held with a financial institution.

Referring now toFIGS. 1 and 2, exemplary aspects of a compliance workflow and system architecture that can be configured and employed in accordance with embodiments of the present invention are illustrated. As shown, at step202, one or more customers102can communicate identifying data which is received by a customer processing system104A of a customer identification program (“CIP”)104maintained and operated by a financial institution106. The customers102may be shareholders seeking to initiate and maintain investment accounts with the financial institution106, for example. As discussed in more detail herein, the CIP104allows the financial institution106(and/or the financial institution106operating through or in cooperation with a transfer agent107) to perform risk-based analyses in association with compliance with relevant portions of the Patriot Act, for example, including verifying the identity of each new customer who opens an account with the financial institution106. The financial institution106may be a mutual fund, for example, or a third party entity that has been engaged to provide CIP services on behalf of a mutual fund. The financial institution106may be a transfer agent, for example, that a mutual fund has employed to provide CIP services. The transfer agent may provide CIP services in addition to performing recordkeeping functions for the mutual fund.

The customer processing system104A may be operatively associated with one or more computer systems, for example, that facilitate the collection and processing of identifying data or other information received from the customers102. The customer processing system104A may include a transfer agent recordkeeping system and/or imaging system, for example, configured with one or more functions that assist with one or more of the following processes: (1) defining who the customer102is in each type of account that might be operated by the financial institution106; (2) determining which customers102need to be verified and which do not have to be verified in accordance with Patriot Act requirements; (3) and/or, if the customer102has to be verified, identifying what entity involved in the relationship with the financial institution106should be deemed the customer102, especially if a corporation, trust, retirement plan or other such business entity is involved. The identifying data obtained by the customer processing system104A from the customers102in step202may include, without limitation, name, street address, government-issued identification number (e.g., social security number (“SSN”) or tax identification number (“TIN”)), date of birth (with respect to individuals), and/or a variety of other kinds of identifying data. Also, various supporting documentation may be requested from the customers102and received by the customer processing system104A at step204in connection with execution of the CIP104by the financial institution106.

To assist in execution of the CIP104, various embodiments of the invention may employ one or more customer matrices104B (at step206) and/or one or more scenario matrices104C (at step208). Aspects of an exemplary customer matrix104B are illustrated inFIGS. 3A through 3H; and, aspects of an exemplary scenario matrix104C are illustrated inFIGS. 4A through 4D. It can be appreciated that the matrices104B,104C can be employed in association with gathering and analyzing identifying data from the customers102including certain required data elements such as government-issued identification including SSN and TIN information, for example, that may be necessary for Patriot Act compliance. The matrices104B,104C are structured to account for multiple permutations that may arise during the operation of the customer processing system104A in receiving and processing new customer102information. The matrices104B,104C may be embodied and executed in computer software or other suitable computer-readable media configured to operate in association with the customer processing system104A for analyzing identifying data and/or other information received from the customers102.

As shown inFIGS. 3A through 3H, the customer matrix104B provides a tool for determining whether the CIP104is applicable to various customers102; and, if the CIP104applies, who the customer102is in the relationship with the financial institution106, what information is required from the customer102, and/or what supporting documentation should be obtained from the customer102. In the example shown, the customer matrix104B may be organized by account category302and account type304and provide an indication306of whether or not the CIP104applies to the customer102, as well as an indication308of who should be the customer102. The customer matrix104B may also include a section310for identifying data to be obtained in addition to predefined necessary data elements such as name, address, SSN/TIN, and date of birth information; a section312for designating supporting documentation to be obtained from customers102when a new account application is submitted, for example; and, a section314for additional comments that may be employed in association with evaluating applicability or treatment of a given account category302and account type304with respect to the CIP104.

For example, with reference to line350ofFIG. 3A, a “businesses” account category302and a “partnership” account type304illustrate application of the customer matrix104B to a customer102interacting with the financial institution106. In this example, the matrix104B indicates in section306that the CIP104applies; in section308that the customer102is “the partnership”; and, in section310, that information to obtain from the customer102includes “data elements of the general partners.” The customer matrix104B also indicates, in section312for purposes of this example, that a certified copy of the partnership articles or agreement should be obtained from the customer (see reference to “documentation notes” in section312, which cross-references information shown inFIG. 3H). The matrix104B further indicates in section314that, “verification of general partners may be performed” by the financial institution106in association with the processing activity of the CIP104.

In addition, the scenario matrix104C can provide guidance for determining CIP104applicability under a variety of circumstances associated with customer102accounts and/or customer102transactions. In the example shown inFIGS. 4A through 4D, the scenario matrix104C includes a section402for explaining a scenario that might be encountered by the CIP104; a section404that indicates whether the required data elements should be obtained for the given scenario; and, a section406that explains the reasoning behind the decision built into the matrix104C to obtain the required data elements. For example, at scenario number 3 ofFIG. 4A, application of the scenario matrix104C provides that the required data elements need not be obtained (see section454) for a customer previously verified through the CIP104after Oct. 1, 2003 (see section452), because the data elements would have been collected from the customer when the customer first opened an account on or after Oct. 1, 2003 (see section456).

If the financial institution106determines during the identifying data collection process that a customer102application does not include the necessary data elements, the financial institution106may reestablish contact with the customer102or a representative of the customer102(e.g., a broker) to obtain the required data elements. It can be seen that, subject to the requirements of the Patriot Act, existing customers102of the financial institution106may or may not need to be processed through the CIP104.

With reference toFIG. 5, the customers102, the financial institution106, and the clients112may communicate with and access the CIP104in various ways. These entities102,106,112may interact with the CIP104by using one or more access devices152operating through one or more different communication media154. Examples of access devices152include, without limitation, computer systems152A, personal digital assistants (PDA's)152B, notebook computers152C, and/or telephones152D (of either wireless or wireline variety). Examples of communication media154include, without limitation, wireless data networks154A, wireline networks154B, and/or various networked media154C (e.g., the Internet). Communications conducted by operation of the access devices152through the communication media154may be secured or encrypted by means of conventional security devices or processes.

Referring again toFIGS. 1 and 2, in various embodiments, the CIP104includes a compliance database104D that assists with the process of conducting verification of customers102in accordance with the requirements of the Patriot Act, for example. In general, the compliance database104D acts as a gatekeeper or common processing point between/among the customer processing system104A, one or more government list matching functions108, and one or more verification vendors110. At step210, on a periodic or non-periodic basis, customer102information is collected or extracted from the customer processing system104A and received in the compliance database104D, wherein a record for each customer102for whom the CIP104has identified as requiring verification is created and stored. The compliance database104D can be configured to maintain physical and/or logical separation of customer102data for multiple financial institutions106or clients112of the financial institution106. This functionality enables the CIP104to maintain records at the customer102level, rather than merely at the shareholder account level, for example.

As discussed in more detail below, the compliance database104D stores verification results records obtained from the government list matching functions108, and processing through use of the verification vendors110. The compliance database104D can be configured to store required identification information provided by each new customer102, the verification method or methods used, the results of each verification method, and/or the resolution of any substantive discrepancies discovered during the identity verification process. In addition, electronic images of new account applications and supporting documentation can be stored in an imaging system operatively associated with the customer processing system104A and/or in the database104D. Storage of database records and document images can address recordkeeping requirements relating to information relied upon by the financial institution106in connection with verifying identifying data of customers102and confirming the validity of the verification process executed by the CIP104.

At step212, the CIP104may employ an automated functionality to search records in the compliance database104D with one or more of the government list functions108to determine if customer102data appears on a government list of known or suspected terrorists or terrorist organizations. For example, the customer data may be compared against the Office of Foreign Assets Control's lists of Specially Designated Nationals and sanctioned countries to determine if matches or potential matches exist. The financial institution106may take appropriate action, including blocking an account and/or notifying its clients112of any confirmed matches arising from use of the government list matching functions108.

At step214, data may be extracted from the compliance database104D for unverified customers and communicated electronically to the verification vendors110. In various embodiments of the invention, a first vendor110may be used for individual customers102and a second vendor110may be used for entity customers102. An example of a vendor110used for individual customers is “Acxiom”; and an example of a vendor110used for entity type customers102is “Dun & Bradstreet”. The CIP104of the present invention thus may utilize different vendors for individuals and entities, leveraging these different vendors areas of expertise with customer102data. In general, the verification vendors110compare the customer102data received from the compliance database104D against their records in step216to determine the degree to which the data from the database104D matches their vendor110data. This matching of the database104D data against the vendor110data can be performed in an electronic, non-documentary manner.

Once processing of the customer102data by the vendors110is completed, the verification vendors110may transmit the processed customer102records back to the compliance database104D in step218with an indication of the degree to which the database data matches the vendor110data. This verification vendor110transmission may update the customer102records in the compliance database104D with additional data concerning the verification status of the data, such as an indication of verification pass/fail and/or a verification score, for example. Based on the degree to which the data is matched, as determined by application of predetermined criteria, the CIP104may mark the customer's102identity data in step220as verified or not verified. Customer records not marked as verified may then be placed in one or more queues within the compliance database104D in step222for further verification processing in step224. In various embodiments, the customer102data returned from the vendors110that cannot be marked as verified may be electronically re-transmitted to one or more additional vendors110, for example, for further processing substantially similar to the vendor110processing of step214.

For further verification processing of unverified customer102records in step224, the financial institution106may employ one or more identity verification tools provided by the verification vendors110to determine if the vendor110has sufficient information to enable the financial institution106to verify the identifying data of the customer102. The further verification processing of step224may also involve direct contact (e.g., e-mails, telephone calls, etc.) by the financial institution106with the customer102to attempt to form a reasonable belief that the identity of the customer102can be verified. Personnel of the financial institution106may also perform a variety of other research functions as part of the further verification processing activity to attempt to verify the unverified customer102records in the compliance database104D.

If the further verification processing is successful at verifying the identity of the customer102, then the customer102record in the compliance database104D can be updated accordingly at step226. If the further verification processing is unsuccessful at verifying the identity of the customer102, however, then a CIP case can be created for the customer102record at step228. The results of the further verification processing efforts may be input into the compliance database104D at step226and retained for future reference in compliance with applicable record keeping requirements of the Patriot Act. When the CIP104is unable to verify the identifying data of a customer102, a resolution code may be placed on the account or accounts associated with the customer102at step226that prevents future activity by the customer102(e.g., investments or exchanges between fund portfolios) with the financial institution106. The customer102or a representative of the customer102may be notified of this action. In certain circumstances, additional action may be taken relative to a CIP case, such as closing the account of the customer102.

The following description includes examples of various aspects of the compliance database104D to illustrate how it may be employed within the CIP104to assist with verifying customer102identifying data. These examples are intended to illustrate possible embodiments of the present invention for those skilled in the art and are not necessarily intended to limit the scope of the present invention.

Referring now toFIG. 6, a main menu screen display602can be accessed by a user of the compliance database104D. The main menu screen display602includes links to various functions that can be performed within the compliance database104D. A “Contact Inquiry” function604can be used to access specific customer102records. An “Open/Resolved Contacts” function606can be accessed to view a list of customer102records by resolution code, or by their verified or unverified status. A “Queue Menu” function608provides a list of work queues, such as a work queue that includes unverified customer102records that require further verification processing. Also, a “Contact Assignment” function610and a “Contact Re-Assignment” function612permit assignment or re-assignment of customer102records for further verification processing by specific users of the compliance database104D. It can be seen that the compliance database104D provides work queue capability whereby customer102records can be assigned to specific users based on various criteria such as by a particular client of the financial institution106or by predetermined priority values assigned to the customer102records.

Referring now toFIG. 7, an inquiry screen display702provides the ability for database104D users to access customer102records for either inquiry or maintenance purposes. Inquiries may be performed by compliance database104D reference number704, by bank number706, by account type708, and/or by account number710. Once an inquiry is submitted, either a results list can be displayed (from which a specific customer102record could be selected), or the selected customer102record details can be displayed.

As shown inFIG. 8, a screen display802provides the ability for users to access and work a list of open and resolved items to which they have been assigned. Functions associated with this screen display802allow the user to perform a detailed selection/sort of customer102records by certain criteria such as by user, by financial institution106or client112, by assigned or unassigned, by resolution code, or by a date/time range. The detailed selection/sort criteria can be configured to default to assigned/open work items in priority order, then by date within priority for that user. Once search results are returned, the user may enter the number corresponding to the record to be reviewed and begin working through assigned items. Any individual criterion or combination of the selection criteria may be selected, resulting in a summary listing of all customer102records that meet the criteria. For example, an “Open Items” search may yield a list that represents a particular user's work queue, including customer102records that are to be researched and resolved as part of further verification processing. It can be seen that the compliance database104D permits users to access current open items as well as a list of previously resolved items associated with verification of customer102records. Users can also update open items with results of research and/or update the status of the item as part of further verification processing activity.

Once a record has been selected, detailed customer102record information can be displayed as shown in the screen display902ofFIG. 9. This screen display902may include customer102CIP data and verification data. In addition to the fields provided in the detail record screen display902, the user can also enter free-form text into a comments section904associated with the screen display902. Such comments may reflect the results of further verification processing activity performed in association with one or more customer102records.

Referring now toFIG. 10, additional data including vendor110data can be provided on a screen display1002. This screen display1002may include address information or scoring data, for example, obtained from one or more of the verification vendors110. In operation of the compliance database104B, a priority of a customer102record can be set automatically when the record is received from the vendor110based on a score applied by the vendor110. Priority of customer102records can also be established based on various factors, including whether the customer102is an entity or individual, whether a match with a government list108exists, or what financial institution106and/or client112may be associated with the customer102record. One or more work queues of the compliance database104D can be configured to sort customer102records automatically by priority. The queuing process allows for queue criteria to be determined at the client level, or on an individual financial institution106or client112basis. For example, a given financial institution106may desire to create a queue of records deemed to be high-priority items that have achieved a threshold vendor110score. It can be seen that prioritized customer102records can be readily split into multiple populations of records that are subject to further verification processing in accordance with their priority. In various embodiments, customer102records transmitted from the vendors110having achieved a predetermined vendor score level may be automatically deemed resolved or verified by the CIP104. Scores provided by the vendors110that summarize degree of similarity between components of the customer102record supplied by the compliance database104D and the vendor110reference information may be mapped to confidence intervals (e.g., on a 1-10 scale) that indicate the confidence of the vendor110that its reference information matches the customer102record.

In various embodiments, one or more of the following criteria may be used by the verification vendors110in the identity verification process: name and address match; name and social security number match; social security number is valid; social security number has not been reported as deceased; and/or, number of individuals associated with the social security number is not greater than a predefined threshold. If any of the foregoing criteria is not met, then a customer102record may be deemed to be a CIP case that is stored in a work queue in the compliance database104D. If all of the criteria are met, then the customer102record may be deemed to be verified by the vendor110, and the record can be automatically updated in the compliance database104D as resolved.

If a customer102record cannot be verified, further verification processing may be conducted to confirm whether or not a manual data entry error, for example, has contributed to the failure to verify the customer102record. Personnel of the financial institution106can review the information returned by the vendor110that explains why the customer102record has failed the vendor110verification process (e.g., name and address do not match). In connection with this review, original source documents received from the customer102and stored in the compliance database104D may be viewed to determine potential causes for the failure to verify the customer102record.

In various embodiments of the invention, one or more reports can be generated based on statistical data obtained from operation of the CIP104. Such reports may include data associated with customers102that failed the verification process, customers102that the financial institution106was able to subsequently verify during further verification processing, accounts on which a stop purchase/credit code has been placed due to failure of verification, and/or other statistical data.

It can be seen that embodiments of the present invention may be structured to support functions performed by a record keeper, such as a mutual fund transfer agent, for example, who has responsibility for processing new accounts on behalf of a mutual fund that has a CIP requirement. In addition to supporting CIP requirements, however, the CIP104including the compliance database104D may also be used in connection with anti-money laundering and/or fraud detection programs.

The examples presented herein are intended to illustrate potential and specific implementations of the present invention. It can be appreciated that the examples are intended primarily for purposes of illustration of the invention for those skilled in the art. No particular aspect or aspects of the examples is/are intended to limit the scope of the present invention.

It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, other elements. For example, certain operating system details and modules of network platforms are not described herein. Those of ordinary skill in the art will recognize, however, that these and other elements may be desirable in a typical computer system or database system. However, because such elements are well known in the art and because they do not facilitate a better understanding of the present invention, a discussion of such elements is not provided herein.

Any element expressed herein as a means for performing a specified function is to encompass any way of performing that function including, for example, a combination of elements that perform that function. Furthermore the invention, as defined by such means-plus-function claims, resides in the fact that the functionalities provided by the various recited means are combined and brought together in a manner as defined by the appended claims. Therefore, any means that can provide such functionalities may be considered equivalents to the means shown herein.

In general, it will be apparent to one of ordinary skill in the art that some of the embodiments as described hereinabove may be implemented in many different embodiments of software, firmware, and/or hardware. The software code or specialized control hardware used to implement some of the present embodiments is not limiting of the present invention. For example, the embodiments described hereinabove may be implemented in computer software using any suitable computer software language type such as, for example, C or C++ using, for example, conventional or object-oriented techniques. Such software may be stored on any type of suitable computer-readable medium or media such as, for example, a magnetic or optical storage medium. Thus, the operation and behavior of the embodiments are described without specific reference to the actual software code or specialized hardware components. The absence of such specific references is feasible because it is clearly understood that artisans of ordinary skill would be able to design software and control hardware to implement the embodiments of the present invention based on the description herein with only a reasonable effort and without undue experimentation.

Moreover, the processes associated with the present embodiments may be executed by programmable equipment, such as computers. Software that may cause programmable equipment to execute the processes may be stored in any storage device, such as, for example, a computer system (non-volatile) memory, an optical disk, magnetic tape, or magnetic disk. Furthermore, some of the processes may be programmed when the computer system is manufactured or via a computer-readable medium. Such a medium may include any of the forms listed above with respect to storage devices and may further include, for example, a carrier wave modulated, or otherwise manipulated, to convey instructions that may be read, demodulated/decoded and executed by a computer.

It can also be appreciated that certain process aspects described herein may be performed using instructions stored on a computer-readable medium or media that direct a computer system to perform process steps. A computer-readable medium may include, for example, memory devices such as diskettes, compact discs of both read-only and read/write varieties, optical disk drives, and hard disk drives. A computer-readable medium may also include memory storage that may be physical, virtual, permanent, temporary, semi-permanent and/or semi-temporary. A computer-readable medium may further include one or more data signals transmitted on one or more carrier waves.

A “computer” or “computer system” may be, for example, a wireless or wireline variety of a microcomputer, minicomputer, server, mainframe, laptop, personal data assistant (PDA), wireless e-mail device (e.g., “BlackBerry” trade-designated devices), cellular phone, pager, processor, fax machine, scanner, or any other programmable device configured to transmit and receive data over a network. Computer devices disclosed herein may include memory for storing certain software applications used in obtaining, processing and communicating data. It can be appreciated that such memory may be internal or external to the disclosed embodiments. The memory may also include any means for storing software, including a hard disk, an optical disk, floppy disk, ROM (read only memory), RAM (random access memory), PROM (programmable ROM), EEPROM (electrically erasable PROM), and other computer-readable media.

In various embodiments of the present invention disclosed herein, a single component may be replaced by multiple components, and multiple components may be replaced by a single component, to perform a given function or functions. Except where such substitution would not be operative to practice embodiments of the present invention, such substitution is within the scope of the present invention: Any of the servers described herein, for example, may be replaced by a “server farm” or other grouping of networked servers that are located and configured for cooperative functions. It can be appreciated that a server farm may serve to distribute workload between/among individual components of the farm and may expedite computing processes by harnessing the collective and cooperative power of multiple servers. Such server farms may employ load-balancing software that accomplishes tasks such as, for example, tracking demand for processing power from different machines, prioritizing and scheduling tasks based on network demand, and/or providing backup contingency in the event of component failure or reduction in operability.

While various embodiments of the invention have been described herein, it should be apparent, however, that various modifications, alterations and adaptations to those embodiments may occur to persons skilled in the art with the attainment of some or all of the advantages of the present invention. The disclosed embodiments are therefore intended to include all such modifications, alterations and adaptations without departing from the scope and spirit of the present invention as set forth in the appended claims.