Processor-Based Systems and Computer-Implemented Methods for Identification, Sourcing, and Acquisition of Distressed Debt

Disclosed herein are processor-based systems and computer-implemented methods for identification, sourcing, and acquisition of distressed debt. At least one embodiment provides amalgamated debt information associated with an indebted entity, which may owe debt to multiple disparate lending entities. Often, debt information involving these lending entities is maintained in a number of unassociated and disparate data sources, to which access may be restricted on a subscriber basis. To provide amalgamated debt information associated with the indebted entity, a computer platform is programmed to carry out at least one of searching and receiving debt information that is associated with the indebted entity and that identifies some or all of the multiple disparate lending entities. The platform is programmed to amalgamate and organize the debt information, and to present the amalgamated-and-organized debt information via a user interface, providing consolidated access to the unassociated and disparate data sources.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1is a simplified diagram of a communications system in which at least one embodiment can be carried out. As can be seen inFIG. 1, the communication system (indicated generally at100) includes a packet-data network102communicatively coupled with a packet-data network104. In at least one embodiment, network102is a private (e.g., corporate) packet-data network, and network104is a public, perhaps global, packet-data network (e.g., the Internet). In at least one embodiment, networks102and104support the well-known TCP/IP (Transport Control Protocol/Internet Protocol) protocol suite, and entities residing on those networks are addressable using IP addresses. In at least one embodiment, entities residing on network102and not (directly) on network104may each be assigned a private IP address (e.g., 192.168.1.101), while entities addressable over network104may each be assigned at least one publicly routable (i.e., global) IP address. It is noted that IPv4, IPv6, and/or any other suitable protocol may be utilized in a given implementation.

As can also be seen inFIG. 1, the communication system100includes computing devices106and108communicatively coupled to network102. This depiction and description of two computing devices being communicatively coupled to network102is by way of example only, as any suitable number of such computing devices may be present in a given implementation. As a general matter, the depiction and description of the particular types and quantities of entities, devices, systems, networks, etc. in connection with the presently disclosed systems and methods are meant by way of illustration and not limitation. Any suitable number of computing devices, networks, and so on may be used in a given implementation, and the functions described herein as being carried out by one or more computing devices, entities, etc. may be carried out by way of one or more processors executing instructions stored as software, firmware, and/or hardware, as seen fit by the designer(s) of a given implementation.

And it should be further noted that the term “system” as used to describe communication system100is not meant to be interchangeable with the term “system” as used in the claims, in phrasing such as “the present systems and methods,” and the like, where a system could take the form of a single computing device, a part of a single computing device, a combination of cooperating computing devices, and/or any other permutation or combination deemed suitable for a given implementation.

Returning attention toFIG. 1, one or both of the computing devices106and108may include a user interface, a communication interface, at least one processor, and some form of data storage having stored thereon instructions executable by their respective at least one processor for carrying out the computing-device functions described herein. Note that computing devices106and108could be instances of the exact same type of computing device, but could just as well be instances of two different types of computing devices. Computing device106and/or computing device108could fit the description given with respect to computing device800ofFIG. 8. As examples, one or both of computing devices106and108could be or include a laptop computer, a desktop computer, a tablet device, a cell phone, a personal digital assistant (PDA), and/or any other suitable device or devices.

InFIG. 1, communication system100is depicted as also including four data sources110,112,114, and116that are each communicatively connected to network104, and that each may comprise one or more servers having network interfaces, processors, data storage, etc. as is known in the art. Of course, as stated above more generally, and as applied specifically here, there could be fewer or a greater number of data sources present in a given implementation, and one or more data sources could be communicatively connected to a different network, as the depiction inFIG. 1of four data sources that are each separately communicatively connected to network104is by way of illustration and not limitation. The nature, data content, functionality, etc. of these various data sources is described in the balance of this description of the presently disclosed systems and methods. As but two illustrative examples, data source110could be a loan-profile-record (e.g., loan-origination-document) data source such as DealScan®, while data source112could be an SPV-modeling data source such as Intex®.

FIG. 2is a broad-stroke, high-level conceptual view of the present system, showing the present computing system (i.e., platform)250in the center of the hub-and-spokes configuration. And around the outside ofFIG. 2, each connected to the platform250is a number of data sources and capabilities that, to some extent, provide a bird's-eye view of the system. In counterclockwise order, those data sources and capabilities of the presently disclosed systems and methods are: Proprietary Research202, Loan Legal Documents204, Loan Universe206, Portfolio Company Financial Reporting208, Bank Work-Out Loans210, Bankruptcy Documents212, Research Portal214, Syndication Information/Materials216, Transaction Memoranda218, Lender Group Information220, and Private Information222.FIG. 2is but one way to conceptualize the present systems and methods, and is presented to aid the reader's conceptual understanding, but is not presented to offer any explicit or implied limitations as to the data sources and/or capabilities that may be present in various embodiments.

FIG. 3is a screenshot300of a user interface in accordance with at least one embodiment. As shown inFIG. 3, screenshot300shows a series of tabs (302,402, etc.) near the top, with a transaction tab302shown as currently selected, as is known in the art. Tab302includes a target-universe region304, a transaction-due-diligence region306, a research-and-reporting region308, a transaction-profile-data region310, a save button312, a team dropdown314, a status dropdown315, a company dropdown316, an ID field317, and an analyst field318.

In general, transaction tab302is a bit of a “home page” for the private-equity professionals using the system, and it facilitates these professionals being able to “slice and dice” the key data with which they work in different ways and with respect to different transactions (i.e., with respect to different efforts at different stages of completion (or potential completion) to obtain controlling interests in different target companies). In various embodiments, one or more of the dropdowns could be proactive (i.e., can be used to select transactions by team, status, or company, etc., potentially resulting in one or more other dropdowns and/or data fields being responsively populated, updated, etc., as is known in the art) and/or reactive (i.e., their value updates in response to manipulation of one or more other menus, etc., as is known in the art).

And it should be appreciated thatFIGS. 3-6are by way of example, and that different combinations, subsets, supersets, arrangements, etc. of the presented data could be used in various implementations without departing from the scope or spirit of the present disclosure. Additionally, while a fair amount of detail is provided in (and about)FIGS. 3-6(among others), not every aspect of each of these figures is exhaustively described in this description; this is due to a number of considerations, one of which is the self-evident nature of certain simple user-interface elements (e.g., fields for name, address, etc.), another of which is that those of skill in the art will readily appreciate the purpose and function of various user-interface elements (e.g., many of the back-office functions depicted onFIG. 6), and another of which is simple clarity of presentation, of course not to the exclusion of any one or more other considerations.

Returning toFIG. 3, it can be seen that the target-universe region304includes a target-list button320, a target-equity button322, a target-debt-universe button324, and a distressed-loan-universe button326. These user-interface elements320-326may be operative in various embodiments to present different slices or cross-sections of different subsets of data that the present system has mined and organized from various data sources, as described herein.

Selection of the target-list button320may bring up a detailed list of the various target companies that the private-equity firm has decided to attempt to acquire, perhaps including some that the firm has already started to attempt to acquire. This list may be in tabular form, and may include additional data fields (address, web address, etc.) about each target, and may also be populated with data reflecting their current debt situation, perhaps as well as links to associated loan-profile records, along with data reflecting the extent to which the pieces of that company's debt have been identified, located, acquired, etc. using the present systems and methods.

That is, the present system may receive loan-profile-record data from one or more sources, and thereby associate target companies with debts that may well be distressed, and furthermore receive SPV-modeling data from one or more sources, and mine that data to identify associations between the debts at the macro level and the debt pieces at the micro level; and furthermore associate—e.g., by relational-database techniques—data regarding these debts and their respective debt pieces. Putting all of this information (including but not limited to (1) data identifying companies likely to have distressed debt and attractive assets, associated with (2) data identifying those debts themselves at the macro level, associated with (3) data identifying many if not all of the pieces of those debts (i.e., where to find them)) at the fingertips of the private-equity professionals in this organized, distilled, and interconnected manner provides numerous advantageous efficiencies and capabilities with respect to the professionals′ efforts to profitably engage in the control investing of private equity in distressed-debt assets.

Selection of the target-equity button322may bring up a tabular readout of much of the same information, though this time focused on the assets of the target companies rather than on their debts, to assist the private-equity professionals in their evaluations and acquisitions.

Selection of the target-debt-universe button324may bring up a tabular readout of much of the same information described above in connection with target-list button320, though organized not by the target company but by the pieces of debt that the private-equity firm has decided to acquire (or at least attempt to acquire, investigate whether to try to acquire, etc.). In at least one embodiment, this data is viewable (i.e., sortable) in a manner that is grouped by the larger debt (i.e., the particular original loan) from which the farmed-out pieces derive, by the downstream lending institution that currently holds the particular pieces, by the servicing agent, and/or by one or more other properties of the debt pieces.

Selection of the distressed-loan-universe button326may bring up a tabular readout that is organized according to loans on the “macro level” (as that term is used herein), and that includes data on all or substantially all of those loans that the private-equity firm is evaluating as potentially distressed; i.e., the scope of data presented in response to selection of this function may be investments under consideration, organized on the macro-loan level. And certainly it is contemplated that this readout, as with all others disclosed herein, is sortable, viewable, filterable, etc. by one or more properties, as is known in the programming arts.

As mentioned above, the transaction tab302includes a transaction-due-diligence region306, which generally provides users with an interface to store and access data that pertains to the detailed review (i.e., the due diligence) that the private-equity firm performs in connection with companies that the firm has decided to acquire, or at least to seriously look into acquiring. As can be seen, this region of the user interface provides the user with access to the due-diligence file being kept for a particular transaction, financial statements, legal records, lender-group information, sourcing (i.e., directly pertaining to the investigation into and (typically piecewise) acquisition of the debt of the target company.

And region306further includes a portfolio-company-reporting function (e.g., button)338, the activation of which presents to the user data that has been reported by the target (or perhaps, by that stage, acquired) company to the private-equity firm; in an embodiment, the system provides automatic and/or manually triggered prompts to one or more people at the target company, requesting that they provide specific information to the private-equity firm in a specific format, to standardize and normalize the firm's operations to some extent.

In at least one embodiment, the transaction tab302includes a transaction-profile-data region310, which generally provides users with an interface to store and access data that pertains to the basic bibliographic and other basic details of a given target acquisition, such as name, address, names of executives, industry and ratings, identification of one or more advisors and or one or more auditors associated with the transaction, identification of one or more sponsors, bank-deal status, security status, and/or one or more other details and/or data fields.

FIG. 4depicts a screenshot with a sourcing tab402having been selected. As can been inFIG. 4, this tab includes an institution-name dropdown404, a coverage dropdown406, a reports dropdown408, a sourcing-institution-specific-contact-details region410, a sourcing-institution-general-information region412, and a communication-history-and-follow-up-plans region414. As can be appreciated from this written description in general and from a review ofFIG. 4, tab402serves as an easily accessible interface to the sourcing-tracker functionality discussed above, and in general tab402facilitates the private-equity professionals being able to maintain and nurture relationships with contacts at various lending institutions.

FIG. 5shows an entities tab502having a hedge-fund-data region504and a control-investing-fund-data region506. Both of these regions provide dropdowns (which, like the other dropdowns described herein, could be proactive and/or reactive) pertaining to looking up various SPVs and various funds that may be held by a firm's hedge fund or control-investing fund, respectively. And both of these regions further include data-readout areas512,514,520, and522where data for selected SPVs, etc. may be viewed and/or updated. Note that the premise of tab502is that the associated private-equity firm maintains a hedge fund separate from a control-investing fund, where a given investor might invest in either, both, or neither. But this premise is merely illustrative and should in no way be interpreted as necessarily present in every embodiment of the presently disclosed methods and systems.

FIG. 6depicts a back-office-functions tab602having a number of regions, including an actual/potential-investors region604, an other-investment(s) region606, a global-market-data region608, a trading region610, an accounting region612, a financing region614, and a settlement region616. These various back-office functions are generally known to those of skill in the art, and thus are not described in great detail here. And it should be noted that one or more different and/or additional back-office functions (human resources, etc.) could be provided by the system and perhaps represented on a display such as tab602. Region604may provide functionality with respect to individual investors, groups of investors, investor institutions, and the like in a manner similar to the functionality provided by tab402with respect to lending institutions. Region606may provide an interface for storing, accessing, updating, etc. information regarding other investments (such as real estate) that the given private-equity firm may hold from time to time. And the regions608-616provide back-office functionality with which those of skill in the art are familiar.

FIG. 7is a flowchart depicting functions carried out in accordance with at least one embodiment. In particular,FIG. 7depicts a method700described as being carried out by a computing system that comprises at least one user interface, at least one communication interface, at least one processor, and data storage having stored thereon instructions executable by the at least one processor for carrying out the recited functions. In at least one embodiment, the at least one user interface comprises at least one visual display. In particular, method700may be carried out by computing device106, though this is of course just an example. And it is noted that the steps recited as being carried out as part of method700need not necessarily be carried out in the order in which those steps are described.

Method700begins at step702, with the computing system receiving loan-profile data records from at least one loan-profile data source. Each loan-profile data record is associated with an original loan from a respective original lender to a respective original borrower for a respective original loan amount. And each received loan-profile data record includes data that reflects one or more loan characteristics of the loan associated with that loan-profile data record. In at least one embodiment, step702involves at least one loan-profile data record being manually downloaded. In at least one embodiment, step702involves at least one loan-profile data record being downloaded in at least one automated manner, which as examples could take the form of or at least involve at least one of execution of at least one macro, execution of a least one script, and execution of at least one batch download.

Method700continues at step704, with the computing system storing at least a subset of the received loan-profile data records in a manner that is organized at least in part according to at least one loan characteristic included in the respective received loan-profile data records. In at least one embodiment, step704involves at least one loan-profile data record being manually stored in that manner. In at least one embodiment, step704involves at least one loan-profile data record being stored in that manner in at least one automated manner, which as examples could take the form of or at least involve at least one of file-type conversion, batch file-type conversion, optical character recognition (OCR), and parsing.

In at least one embodiment, the one or more loan characteristics according to which the stored loan-profile data records are at least in part organized includes one or more of original lender, original borrower, original loan amount, transaction type, transaction date, and agent bank. In at least one embodiment, the manner in which these records are organized takes the form of or at least includes a file-naming convention where the file names reflects at least one such loan characteristic. In at least one embodiment, the manner in which these records are organized takes the form of or at least includes a folder structure wherein the folder contents are determined at least in part by said contents having in common at least one such characteristic. In at least one such embodiment, the referenced folder structure comprises at least two different hierarchical levels of organization respectively organized by two different such characteristics.

Method700continues at step706, with the computing system receiving SPV-modeling data records from at least one SPV-modeling data source. In at least one embodiment, at least one of the received SPV-modeling data records pertains to an SPV selected from the group consisting of a CLO, a CDO, and a CMO. In at least one embodiment, receiving SPV-modeling data records comprises receiving updated data feeds and responsively updating at least one stored association.

Method700continues at step708, with the computing system mining at least a subset of the received SPV-modeling data records to extract therefrom and store associations between respective original loans and respective downstream pieces thereof. The associations include identifications of respective downstream lending institutions currently holding respective downstream pieces of respective original loans.

Method700continues at step710, with the computing system presenting via the at least one user interface (i) access to the stored subset of received loan-profile data records according to the manner in which the subset is stored and (ii) access to the stored associations between respective original loans and respective downstream pieces thereof. The access to the loan-profile data records and the access to the stored associations are correlated with one another by at least one loan characteristic.

In at least one embodiment, the computing system includes a target tracker, which itself includes a target data store and a target user interface. The target data store includes target-company profile records and the stored loan-profile records, and the target user interface provides access to said target-company profile records and stored loan-profile records.

In at least one embodiment, the computing system includes a sourcing tracker, which itself includes a sourcing data store and a sourcing user interface. The sourcing data store includes at least one of contact information, communication-history information, and planned-communication information for one or more contacts at one or more downstream lending institutions. And the sourcing user interface provides access to this information for the one or more contacts, and further provides correlated access between (i) the information regarding the one or more contacts and (ii) the stored associations pertaining respectively to the downstream lending institutions respectively associated with said contacts.

In at least one embodiment, the computing system provides via the at least one user interface a single display comprising respective points of access to respective cross-referenced displays of stored data, where these cross-referenced displays include displays that respectively pertain to target companies, target loans, target pieces of target loans, and a distressed-loan universe. In at least one embodiment, the cross-referenced displays further include at least one of a display that pertains to transaction due diligence, a display that pertains to research and reporting, and a display that pertains to transaction profile data. In at least one embodiment, the system provides all of those cross-referenced displays mentioned in the preceding sentence, arranged on the at least one user interface in a visual sequence that parallels a chronological sequence of a control-investing transaction. And in at least one embodiment, the computing system includes a portfolio-company-reporting function.

FIG. 8is a simplified block diagram of a computing device800that may be used in accordance with at least one embodiment. The computing device800may, in accordance with one or more embodiments, be or include a laptop computer, a tablet computer, a desktop computer, a personal computer, a mobile device, a mobile phone, a personal digital assistant (PDA) and/or one or more other types of computing devices that may be deemed suitable for particular implementations.

In a basic configuration801, computing device800may include one or more processors and/or controllers shown inFIG. 8as processor/controller810and system memory820. A memory bus830can be used for communicating between the processor/controller810and the system memory820. Depending on the desired configuration, processor/controller810can be of any type including but not limited to a microprocessor (μP), a microcontroller (μC), a digital signal processor (DSP), or any combination thereof. A memory controller815can also be used with the processor/controller810, though the memory controller815can be an internal part of the processor/controller810.

Depending on the desired configuration, the system memory820can be of any type including but not limited to volatile memory (such as RAM), non-volatile memory (such as ROM, flash memory, etc.) or any combination thereof. System memory820may have stored thereon one or more applications822and program data824. Application(s)822may include program code such as user-interface program code823. Other process descriptions, steps, or blocks in flow or message diagrams in the present disclosure should be understood as potentially representing modules, segments, or portions of code which include one or more executable instructions stored in application memory822for implementing specific logical functions or steps in the process, and alternate implementations are included within the scope of the disclosed embodiments of the methods in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those of ordinary skill in the art.

Program data824may include, among other things, display characters825that correspond to characters displayed on the user interface implemented via user-interface program code823, and that may be included in display data sent to one or more display devices892. In some embodiments, applications stored in application memory822can be arranged to operate with program data824. Computing device800can have additional features and/or functionality, and additional interfaces to facilitate communications between the basic configuration801and any devices and interfaces. For example, the data storage devices850can be removable storage devices851, non-removable storage devices852, or a combination thereof. Examples of removable storage and non-removable storage devices include magnetic disk devices such as flexible disk drives and hard-disk drives (HDD), optical disk drives such as compact disk (CD) drives or digital versatile (or video) disk (DVD) drives, solid state drives (SSD), tape drives, etc.

System memory820, removable storage media for use with removable storage devices851, and non-removable storage852are all examples of computer storage media, which can include but is not limited to RAM, ROM, EEPROM, flash memory, other memory technology, CD-ROM, DVD, other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage, other magnetic storage devices, and/or any other medium which can be used to store information that can then be accessed by computing device800.

In general, computer storage media can include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer-readable instructions, data structures, program modules, or other data. One or more embodiments may be implemented at least in part in the form of computer program instructions encoded on a non-transitory (e.g., tangible) computer-readable storage medium in a machine-readable-and-machine-executable format.

Computing device800can also include output interfaces860that may include a graphics-processing unit861that can be configured to communicate with various external devices such as display devices892(which may include, for example, a computer screen) or speakers via one or more A/V ports863. External communication circuits880may include a network controller881, which can be arranged to facilitate communications with one or more other computing devices890and/or one or more transmitting and/or receiving devices891.

FIG. 9is a simplified schematic diagram illustrating a conceptual partial view of an example computer program product900on which may be stored a computer program for executing a computer process on a computing device, arranged according to one or more embodiments described herein. In at least one embodiment, the example computer program product900comprises a signal-bearing medium901that has stored thereon one or more program instructions902that, when executed by at least one processor, operate to carry out one or more of the functions described herein.

In at least one embodiment, the signal-bearing medium901encompasses a tangible computer-readable medium903such as but not limited to a hard disk drive, a CD, a DVD, a digital tape, memory, etc. In some implementations, the signal-bearing medium901encompasses a computer-recordable medium904such as but not limited to memory, read/write (R/W) CDs, R/W DVDs, etc. In some implementations, the signal-bearing medium901encompasses a communications medium905such as but not limited to a digital communication medium and/or an analog communication medium (e.g., a fiber-optic cable, a waveguide, a wired communications link, a wireless communication link, etc.).

FIG. 10is a simplified block diagram illustrating an example of data mining in accordance with at least one embodiment. And it should be noted thatFIG. 10is purposefully generalized; it does not depict any particular example of mining any particular data from any particular, e.g., data stream. More generally,FIG. 10depicts data mining so as to extract one or more data values from one or more data streams, data feeds, sets of data records, data stores, etc. The phrasing ofFIG. 10in terms of records, fields, values, table, indices, columns, etc. is used to aid the reader by way of explanation, and is not used by way of limitation.

For illustration,FIG. 10shows a set of data records numbered1000-1005. And the next record is shown including the “ . . . ” character, indicating with each instance of its use that the associated set of elements could include any number of elements, and that the number actually depicted is just an example. And these records could represent all or part of one or more data streams, data feeds, sets of downloaded records, sets of records from a CD-ROM, and/or any other source of data (i.e., data source) that is suitable for a given implementation.

Data record1000is shown as including data fields1000a-1000das an example. In this example, each record includes a corresponding set of data fields (e.g.,1001a-1000d, etc.), though this is for ease of explanation and is not necessarily the case in every implementation. And as indicated by the “ . . . ,” any number of data fields could be present in each record. And each data field could include one or more values of any type of data, such as strings, characters, integers, Boolean variables, floating-point numbers, programming objects, etc. For ease of explanation, each field is depicted inFIG. 10as including a single value of unspecified data type. Thus, field1000ais shown as containing value1000w, and so on.

The brace and the arrows that extend between the set of records1000-1005and the data table1040generically represents the data-mining function, while the data table1040itself generally illustrates an example result of the data mining at a snapshot in time. As is known in the programming arts, data mining typically involves parsing received data to identify and extract one or more data values therefrom.FIG. 10shows an example where the “w” and “y” values of each received record are stored as an ordered pair in connection with an integral index.

In at least one embodiment, the records represent at least part of an SPV-modeling data feed from an SPV modeler such as Intex®, and the extraction-result data table1040might, in a given row, have an index, and/or perhaps a macro-level identifier (where any identifier could be a name, number, a combination thereof, etc.) of a loan (and perhaps also an identifier of the borrower). And each row might further have an identifier of a given piece or set of pieces of that loan, as well as an identifier of the downstream lending institution that currently holds that piece or set of pieces. Thus, a given record from such a data feed might identify the borrower, the loan at the macro level, one or more pieces of the loan, and the respective downstream lending institution that is currently holding that piece or pieces. And the given record likely also includes one or more other data values, such as one or more risk/reward indicators and/or one or more other values of any other type, though the present system mines for storage and presentation only a subset of the data that is received, as described herein.

While various aspects and embodiments have been disclosed herein, others will be apparent to those skilled in the art. The aspects and embodiments disclosed herein are for illustration and are not intended to be limiting, as the true scope and spirit of the present systems and methods is defined by the following claims, along with the full scope of equivalents to which those claims are entitled. It is also to be understood that the terminology used herein is chosen solely for the purpose of describing particular embodiments, and is not intended to be limiting.