WO2005059781A1 - System and method for facilitating trading of debt instruments between parties via an electronic telecommunications network - Google Patents

Abstract

The present invention relates to a system and method for facilitating trading of debt instruments between parties via an electronic telecommunications network, and more particularly concerns such a system and method to allow development of a liquid market in debt assets. Each debt instrument comprises a set of debt instrument attributes, and the method of the invention comprises the steps of inputting debt instrument attributes of a plurality of debt instruments to be offered for sale via the electronic telecommunications network into a database, the debt instrument attributes including obligor information; accessing from a credit bureau dynamic borrower data related to said obligor information; calculating, for a party, pricings for the debt instruments, calculated from said debt instrument attributes and said dynamic borrower data; applying to the pricings a diversification factor based on criteria relating to risk exposure within said party's existing debt instrument portfolio; and selecting a debt instrument in accordance with a comparison of factored debt instrument pricings. The invention provides a method and means by which loans can be accessed by way of a common trading system and user interface, and by which parties are able to exchange information on the loans (with required security de-identification of sensitive data) and price them on the basis of on a common basis of data and assumptions, just as if they were originating these instruments as loans directly to the borrower within their own local loan portfolio. In addition, the invention provides an intelligent trading platform with a decision support interface, allowing the transfer of data required to complete a potential trade which has been accepted by both parties.

Description

System and method for facilitating trading of debt instruments between parties via an electronic telecon-uniinicatioij s network

Field of the invention

The present invention relates to a system and method for facilitating trading of debt instruments between parties via an electronic telecommunications network, and more particularly concerns such a system and method to allow development of a liquid market in debt assets.

Background of the invention

For many years banks and other financial institutions have had access to tools which provide the ability to price loans and credit exposures against their existing portfolios and capital models, in order to allow them to optimise loan terms and pricing. Such systems are generally provided by a bank for access by their staff members via their corporate Intranets. However, with increasing risk concentrations and volatility in financial markets, banks are finding that the availability of reliable vehicles by which to trade loan assets and similar instruments (such as credit derivatives) is extremely limited. The narrow specialised solutions that have existed to date mean that the bulk of bank loans remain illiquid and non- tradeable.

The key to pricing loans is the relative value of the loan or credit derivative with regard to each bank's current portfolio, including its risk concentrations and its 'Economic Capital' - also referred to as 'Credit Capital' (as opposed to its regulatory capital as required by the bank's regulators) . Credit capital is the capital which is required to be kept in reserve for potential defaults within the portfolio, including systemic events which can effect a particular group of loans such as an industry or region grouping. The Credit Capital, which includes an allowance for that bank's concentration risk in particular areas, therefore represents the true costs of making or buying a particular loan, valued by way of measures such as 'Risk Adjusted Return on Capital' (RAROC) . Credit Capital and RAJ OC pricing are therefore key to enabling banks and assets funds to assess the true price for any loan being bought or sold within their existing portfolio.

As mentioned above, the tools currently available for pricing debt instruments are very limited, and most bank loans therefore remain non-tradeable. This situation has been exacerbated by the fact that loan origination and securitisation happen in separate parts of most banking organisations and in functional areas with traditionally different approaches. Summary of the invention

The present invention aims at addressing the problems of the prior art, and to that end there is provided a method for facilitating trading of debt instruments between parties via an electronic telecommunications network, each debt instrument comprising a set of debt instrument attributes including obligor information, debt instrument attributes of a plurality of debt instruments to be offered for sale via the electronic telecommunications network input by the parties into a database, the method including the steps of: a) accessing from a credit bureau dynamic borrower data related to said obligor information; b) calculating, for a party, pricings for the debt instruments, calculated from said debt instrument attributes and said dynamic borrower data; c) applying to the pricings a diversification factor based on criteria relating to risk exposure within said party's existing debt instrument portfolio; and d) selecting one or more debt instruments in accordance with a comparison of factored debt instrument pricings.

Preferably, the method includes the step of transferring data required to complete a debt instrument transfer to or from said party in accordance with said selection step to allow completion of a potential trade which has been accepted by the respective parties..

Preferably, the method includes the step of modelling the impact of a debt instrument transfer on the debt instrument portfolios of two prospective parties to the debt instrument transfer, the modelling step being carried out in accordance with the respective diversification factors of both parties, the selection step carried out in accordance with the result of said modelling step in order to ensure mutual diversification of debt instrument portfolios between the parties. The modelling step may be carried out on the basis of localising debt instruments in accordance with common attributes, to enable analysis on the basis of one or more groupings, such as industry or geographical region groupings.

Step (b) of the above-defined method may involve calculating pricings on the basis of relative pricings of the respective debt instruments between the parties, in accordance with the relative value of prospective trades in those debt instruments as between the parties.

As an alternative, step (b) may involve calculating pricings on a mark-to-market basis, in accordance with the value of the debt instruments relative to other similar instruments available on the wider credit market. Preferably, the method includes the step of accessing captured data relating to the price of offers, bids and/or executed trades of debt instruments to provide information to the value of debt instruments available on the wider credit market.

The debt instrument attributes may be transferred in a common format in the form of metadata definitions, allowing one party using one portfolio management system to interpret debt instrument attributes provided by a party using a different portfolio management system. The metadata definitions based on a Financial Trading Markup Language (FTML) protocol. In a preferred form, the a party may be able to input one or more definitions of new debt instrument attributes not currently defined between said parties; and transferring said one or more definitions to another party, in order to dynamically enhance the range of debt instrument attributes.

Metadata includes a number of attribute descriptors in combination with associated data values for those descriptors. The message handler, data interface and database design are configured to enable interpretation of the metadata by respective parties in such a way that they can be used within their respective portfolio and pricing models.

The debt instrument attributes may be selected from the group including the following:

Obligor information:

^■ Full Name of Corporation or Individual

^■ External identifier (eg Employer Identification Number EIN, Ticker Symbol or other public identifier based on public identification, such as "NYSETICKER:GM" or US-EIN:20303040)

^■ Industry Percentage weighting (a weighting in each industry where the party does business, eg "SIC:10203:100")

^■ Country Percentage (a weighting in each country where the party operates, as a percentage, eg "US:19.5","UK:21.5",PRC:70"

* Probability of default (PD) of the Obligor (as a percentage probability that they will default)

- Volatility of PD (Beta of PD)

Maturity/tenor of debt instrument; Coupon and yield;

Commitment amount; Current drawn amount;

Probability of default of the Loan or Facility itself (LPD).

Volatility of LPD (Beta of LPD)

Status of loan (funded or unfunded); Cashflow and payment schedule;

Collateral information;

Recovery rate in case of default;

Interest rate spread information;

Fees applicable to the debt instrument; ' Price including discount or premium information.

The method thus affords selection of a potential loan trade (or a set of potential loan trades) between the two parties' portfolios, which trade(s) would provide the optimal benefit to both parties by reducing their existing risk concentrations and thereby improving their overall credit risk and use of credit capital.

Further, the method affords selection of a potential loan trade (or a set of potential loan trades) from within a party's portfolio with respect to an overall debt market in which multiple parties trade debt instruments.

Sufficient debt instrument attributes are electronically transferred between parties such that the debt instrument can be evaluated for credit risk, credit capital, income and risk-adjusted returns within the receiving party's portfolio.

Preferably, each party has or employs an internal computer system for managing that party's debt instrument portfolio, the method carried out via the provision of a common database for inputting debt instrument attributes in said common format for each party on their internal computer system. Preferably, the method is carried out via the provision of a common user interface, a set of common business rules, and a data interface for transferring and interpreting the attributes.

Alternatively, a common database for inputting debt instrument attributes in said common format is provided for multiple parties.

The transfer of a debt instrument may be carried out by direct bilateral trading. In preferred embodiment, the transfer is carried out by way of a debt exchange intermediary. Preferably, specified debt instrument attributes input by a party into said database available for use in said calculating step are not made direcdy accessible to other parties. In particular, the system may be configured to suppress identification of one or more of the parties.

Unlike the techniques developed in the prior art, the present invention is thus able, in addition to pricing the effects of the proposed trades between parties, to provide a trade optimiser function (a so-called 'Credit Trade Optimiser') which will allow offerors, buyers and sellers of loans to optimise the selection of trades between the parties and/or against outside markets, in order to find the optimum set of trades for their existing loan or asset portfolio, with regard to available loans or credit derivatives of loans currently offered by a particular counterparty or available currendy within the market place. This optimisation is configured to apply a specific ruleset with regard to a number of relevant factors, including such things as credit capital, regulatory capital and return on capital. This tool allows the isolation by a party of the loans within their current loan or asset portfolio that they wish to optimise. Hitherto, no method or system has been developed or even suggested that is able to transfer sufficient datapoints (obligor and debt instrument attributes) to allow transparency between parties operating separate and otherwise incompatible portfolio management systems.

The optimiser function enables communication with counterparties direcdy or by way of the common debt exchange. Each party is provided with an optimiser, and the system can thus select loans based on user input parameters and prescribed constraints, maximising key performance metrics (such as risk adjusted return, utilisation of credit capital, etc) to maximise the economic benefit for both parties. This process involves an iterative selection of an optimal set of trades between the parties, resulting in the presentation to the users with a set of suggested trades meeting the prescribed parameters and thus meeting the objectives of both parties in terms of diversification and overall risk reduction to the trading portfolios.

As mentioned above, the system and method of the invention involves the use of a common metadata language, FTML, generated by the user selection of options via the system interface. Messages in this language express the prescribed constraints and parameters described above, and can be transmitted to multiple trading counterparties within the exchange, each party being provided with a message handler and data interface for the language. The business objects and the common database reside at each party's internal computer system. Loans meeting the criteria expressed in the message can then be communicated back to the sending party, that user then selecting from the candidate the loans they wish to trade and, where appropriate, selecting to offer counter loans within their own portfolio as an exchange trade.

In a preferred form, the trade markup language, message handler and data interface allow users to define new attributes which are not currendy defined between parties, by a process of querying attributes not currendy defined between them and offering the respective counterparty a choice of potential definitions for them. In this way, a party is able to transfer all key debt instrument attributes required to allow a counterparty to price the debt instrument within their portfolio and pricing model and ensure a commonality of meaning between attributes for their products.

In a further form, the present invention provides a computer-based system for facilitating trading of debt instruments between parties via an electronic telecommunications network, each debt instrument comprising a set of debt instrument attributes, the system including: a logical unit configured to allow input of debt instrument attributes of a plurality of debt instruments via the electronic telecommunications network into a database in a common format, the debt instrument attributes including obligor information; a logical unit configured to access from a credit bureau dynamic borrower data related to the obligor information; a logical unit configured to calculate, for a party, pricings for the debt instruments, calculated from said debt instrument attributes and said dynamic borrower data; a logical unit configured to apply to the pricings a diversification factor based on criteria relating to risk exposure within said party's existing debt instrument portfolio; and a logical unit configured to allow selection a debt instrument in accordance with a comparison of factored debt instrument pricings.

The system may include a debt exchange interface to enable the transfer of data required to complete a debt instrument transfer between parties, so to allow completion of a potential trade which has been accepted by the respective parties. This may be provided by way of a computer system separate from the control of the parties themselves, configured to provide a debt exchange intermediary to facilitate transferring a debt instrument between the parties.

The invention therefore provides a process and means by which loans (and other debt instruments such as credit derivatives) may be accessed by way of a common trading system and user interface, and by which parties are able to price these based on a common basis of data and assumptions, just as if they were originating these instruments as loans directly to the borrower within their own local loan portfolio. Information on potential trades may be transferred between parties, with required security de-identification of sensitive data, allowing each party to carry out analysis of the loans against their own portfolio, in order to assess the relative benefit of those loan trades. Each party is able to set prices and key loan parameters (such as probability of default, or collateral valuation) in this process.

As noted above, the invention also provides a debt exchange, which is an intelligent trading platform with a decision support interface, which allows the transfer of data and details required to complete a potential trade which has been accepted by both parties, thus affording a mechanism for the trading of loans between parties. Enhanced pricing models can be built up based on prices collected on the debt exchange.

In a preferred form, the debt exchange and intelligent trading platform may be made available as callable services or functions (eg, via a Web service), which can also be called by other user interfaces and computer systems.

A party may be a lender (ie a loan originator, such as a bank or similar financial institution), an asset manager or similar in the business of acquiring or exchanging securities based on investment objectives, or may be a securitiser using such exposures to build credit-backed securities.

As noted above, the system can be configured to enable two potential counterparties to value a potential transaction on the basis of 'relative pricing' or 'fair value pricing' between those two parties, based on the relative value of the trade as between the parties and on diversification effects between the parties. Additionally or alternatively, the system may be configured to enable the potential counterparties to a transaction to value a debt instrument on a 'mark-to-market' basis, in accordance with the value of the loans with regard to other similar instruments available in the wider credit markets, such as similar loans or credit derivatives in the market, bonds, notes and commercial paper.

In one embodiment, the system may be configured to enable, with the permission of the participant parties, the capture of information relating to the price of offers, bids and executed trades of debt instruments, so that bids and offers can be viewed by other ' participants as a guide to the current prices in the market for particular categories of deals. Such data capture may include identification of the obligor(s) for the loans being priced or traded, or a de-identified description of the obligor(s) based on data such as size of company, industry, location.

The invention therefore provides a unique solution to the problem of concentration risk and active debt instrument portfolio management by allowing parties to readily trade out of over- weighted positions, based on a high degree of transparency and ability to price debt instruments against the bank's portfolio, in accordance with an accurate assessment of the effects of a debt instrument transaction against the risk-adjusted returns and shareholder value. Optimum trades between counterparties can therefore be selected, based on the diversifying effect between the respective portfolios, and the effect on their respective current holdings, relative portfolio concentrations, and investment requirements.

The invention may be realised by means of a commercial debt exchange (a 'hub' system), providing an intermediary market between buyers and sellers of loans. Such a debt exchange provides a central marketplace for trading, and can assure anonymity between parties and the provision of independent pricing (based on the internal pricing models and bids and offers received on the exchange) .

Alternatively, the invention may be realised directly between parties. In the case of both a central exchange and such bilateral arrangements, the method contemplates measures * trading loans as physical transfers of assets, or by synthetic transfers of credit risk or credit protection and trading via credit default swaps.

Brief description of the drawings For a fuller understanding, a non-limiting embodiment of the invention will now be described with reference to the accompanying drawings, in which: Fig. 1 schematically illustrates a system in accordance with the present invention for enabling trading of loans between parties via an electronic telecommunications network;

Fig. 2 shows a graphical user interface for inter-party loan analysis and trading;

Figs. 3-6 show various screens illustrating tools used by a party to analyse loans and trading scenarios; Fig. 7 shows a trading screen allowing bidding on available loan deals based on the result of the loan analysis;

Fig. 8 illustrates schematically a loan trade process using a standard messaging protocol;

Fig. 9 (9a;9b) further illustrates the various steps of the messaging flow depicted in Fig. 8; and Fig. 10 illustrates the architecture of a loan portfolio management system used to price and benchmark credit risk exposures at origination, for use with the system and method of the invention.

Detailed description of the invention

In this description, reference is made to loans', but it is to be understood that this term is used to refer to all forms of debt instrument that might appear in the commercial portfolio of a financial institution, including term loans, revolving lines of credit, letters of credit, bullet loans, leases, financial market derivatives which may provide credit protection for or create a credit exposure, such as total return swaps, credit default swaps, and credit protection.

'Portfolio theory', as developed by Harry Markowitz and William Sharpe, was first developed in 1952, and is the mathematical foundation of management products for credit exposures, such as RMG's Credit Manager, CSFB's Credit Risk Plus, and Moody/KMVs Portfolio Manager. These allow the modelling of key values for exposures, based on various correlation assumptions and asset data from market information, and many banks have implemented these products or internally developed variants on the same models. In this way the bank's portfolio management group can carry out activities such as spotting the efficiently priced loans from those priced less efficiently, or to isolate loans that are degrading over time or which might represent a migration risk.

However, these known tools involve no more than analysis and modelling, and are fundamentally retrospective in their analysis, looking at existing portfolio returns 'in situ'.

The present invention, in contrast, goes significantly beyond this analysis and modelling to allow banks and other financial institutions to directly and immediately price loans and loan trades on origination or at the point of trade, and therefore drive ongoing (future) business strategies in their portfolio management. Moreover, and as noted above, the invention addresses the current pressing need in many financial institutions to accurately price and reliably liquidate and trade their loan books with each other and with asset funds requiring fixed income instruments. In particular, the invention overcomes the problems of trading in non-standardised assets, in which a large number of data points are required for effective pricing. The relative complexity and non-standardisation of this data means that a significant value (in terms of price and risk adjusted returns) within the banking system is locked in terms of loan assets which cannot be readily offered for sale, priced or traded with other organisations. The relative isolation of institutional loan portfolios from access within the wider financial markets has led to increased vulnerability to loan concentrations, industry and country risk, and localised system faults. In fact, one of the only ways of effectively diversifying portfolios has been via bank mergers which, removing competition in the market for lending, are often undesirable on both an economic and a political level. The present invention addresses the realisation that banks should not necessarily continue to warehouse the loans they originate.

Loans are similar to a class of securities called 'Fixed Income' securities, in that they are mainly traded for their future cash-flows and their effective interest rates (Yield¹), based on the capital amount. Such assets are not traded for an increase in equity value, as there is no transfer of equity in this class of securities. Bonds are similarly fixed interest securities, but require only a few data values for ready pricing by parties (coupon rate, bond term, credit rating, and price). Loans, in contrast, require a large number of data values to be exchanged. Traditionally these data values are not in a consistent format and not available on a consistent basis (such as classification of collateral or terms, or their effect on the capital value). Some require loan equivalent values, others require drawn amounts and limits. In addition, many of these data values are dynamic, such as cash flows. .

Corporate loans are characterised by non-standard cashflow streams, specific risks (which are difficult to identify and quantify), non-standard collaterals and covenants, and relatively complex information transfer between parties.

The present invention overcomes the historical barriers to the development of the loan trading market, namely the non-standardisation of loan agreements, the lack of consensus on what constitutes the key dimensions of risk, the limited application of management tools and the complexity of requisite data exchanges.

The primary components of the system are shown in Figure 1. Two parties connecting to the system are shown as lender terminals 10 and 12 providing common user interfaces, operatively connected to their loan portfolio databases 11 and 13 respectively. The parties are connected via a global communication network 14, such as the Internet, with a debt exchange platform 15 operatively connecting to a database 16 containing user information and associated data.

The system of the invention utilises a common structure and format of database for all users of the system, the database containing all the base data required to calculate the value of a loan either within the originating bank's portfolio or within a purchaser of the credit exposure (as credit derivative based on it) .

The attributes associated with a loan at any time include, for example, the limit of the loan, the current drawn amount, the expected usage of the loan to its limit, the maturity ('tenor') of the loan, interest rates (which may be fixed or spread over a public or benchmark rate), _: collaterals (provided against the risk in case of default, expected recovery rate in case of default (including recoveries on the collaterals), obligor information (including risk rating, according to one or more risk rating methodologies), fees on the loan (paid at inception and during the life of the loan, including up-front fees, usage and non-usage fees), cash flows from the loan (which can involve complex cash flow schedules with grace periods and periods of negative amortisation of the principal) , and any other attributes that may be defined by the loan originator and which may materially affect the loan.

For certain loan parameters, such as covenants or collateral types, parties have hitherto relied on the existence of industry standard (such as SIC codes for industry classification, or ISDA contract forms for financial options and derivative contracts) to assist in comparisons. For a great many types of loans and for many price-critical parameters (such as documentation classes or associated legal covenants), there are no such industry standards, nor likely to be such standards imposed by recognised standards organisations. Banks have in the past set up mutually agreed standards on bilateral bases by relying on loans (such as syndicated loan agreements) for which a given standard is already established in these areas between the syndication banks.

In accordance with the present invention, and as discussed further below, all relevant parameters and their classification between counterparty banks can be set up on an ad hoc basis, by transferring metadata definitions between parties which define the relevant pricing parameters, their classifications and categories and, where appropriate, their calibrations (such as collateral classifications, coding as it relates to a loan group, and expected recovery rates) . Counterparty banks can alter these codings and calibrations to suit their own pricing assumptions, and can use the parameters as inputs to their own analytics and pricing models, before locally pricing the offered loan trades. The transmission of metadata for these underlying pricing parameters and the ability to include new parameters, eg for new trading parties, is a key requirement for effective common pricing and thus for a robust trading system for such complex instruments.

A particular financial organisation may have its own internal pricing models, which attempt to take into account these attributes for the purposes of estimating the capital amount which needs to be reserved with regard to a loan for the risk of default. It may also have models to estimate the likely recovery amount in the event of a default by the obligor (as a percentage of the loan), or loss given recovery rate. Further, in the case of a loan not fully drawn from its limit (such as a line of credit) , there are further models to estimate the amount of the exposure (or drawn amount) at the point of a default ('Exposure-at-Default' models) . Overview The system of the invention is based around a 'Credit Trade Portal' engine and a 'Debt Exchange', delivered via the Internet to users (asset managers and credit traders of financial institutions). The underlying system provides market pricing, based on appropriate analysis and a database of trades. For a particular asset, the system can find the optimal reserve price based on modelling, and quantify the precise effect of a trade (or basket of trades) on a user's portfolio, using appropriate modelling tools.

A preferred embodiment of the system includes some or all of the following components for carrying out the analysis, described in further detail below:

^■ A credit risk database and data warehouse containing all credit exposures and obligor data, including parametric data and scenario loans in negotiation.

^■ On-line analytic programming ('OLAP') providing flexible access, aggregation and manipulation of the underlying data and results from models.

^■ A web-deployed user interface allowing deployment across an enterprise to a large (and scalable) user base.

^■ Component architecture (eg web services, Java or .NET) allowing multiple analysis engines to be deployed and accessed by way of the user interface.

^■ A customisable user interface and component model able to be adapted to new analytics, models, products and external data services.

^■ Capabilities and stress-testing functions, to perform sensitivity analysis on any part of the enterprise's portfolio or market segment.

^■ Push-technology functions allowing the setting of alerts and limits on events and changes in the underlying data (such as credit ratings, countries or industries), based on back-end processing triggers.

Applicant refers to this set of components as a 'Portfolio Insight' system, which embraces a number of specific features, including:

^■ 'SmartCalculations'

^■ 'SmartSentinels'

^■ Linked (or multi-dimensional) Hierarchy structures

^■ Portfolio Stress Testing and 'What if Analysis

^■ Multi-dimensional graphing and visualisation ^■ Credit Trading Portal

Together these components function within the applicant's system as a combined environment of interrelated capabilities. Sector-based stress testing can operate on a dynamically built hierarchy or any branch of it, and a SmartCalculation can be used for this sensitivity analysis, such that any type of stress testing can be performed on different parts of a hierarchy or on specific sectors of the portfolio.

'SmartCalculations'

Generally speaking, a number of areas of analysis cannot be readily modelled by econometric models which operate across all industries, regions or groupings of borrowers. Whereas some models can operate providing they have sufficient data across all countries or industries with equal effectiveness, there are also a number of models which can operate more efficiently local to that region, industry or concentration grouping.

Restricting analysis to only such models that are generic to all industries or every country of the world, or even every size of borrower from small retail to multi-national may well fail to capture useful research information, precluding a number of models that may in fact be extremely effective when localised to a particular region or industry group. In other words, economic models which are generic to all industries often miss the expertise, data and know- how that a bank may have built up over a number of years within a specific industry or region.

With this in mind, SmartCalculations have been developed to allow models to be localised within (a) a particular level within a hierarchy (such as at a relationship or group level) where calculations will only operate at that level but not for other levels in the hierarchy, or, more specifically (b) for particular nodes or branches within a hierarchy such as for particular product types, industries or regions. SmartCalculations can operate on one or a prescribed restricted set of industries, geographic regions, concentration groupings or size of company (based on the design of the hierarchy) to which they are applied. They can be localised to any relevant grouping of loans or obligors and, by making use of dynamic hierarchies, to any possible combination of such groupings. SmartCalculations derive the inputs for the model including details from that specific level or node by way of their ability to access the object model and values within that level or node. They are able to update result values calculated from the model, for that particular node or for any obligors or facilities or detail transactions within that node.

Often models and calculations need to be programmed specifically into the data and user interface environment. Not only does this usual development process require design and development time, it also is restrictive for quantitive analysts and modellers, in that it reduces the scope for prototyping and experimentation during the modelling process.

SmartCalculations allow a model to be developed by modellers and analysts in a number of external environments i such as in MathLab, C and Excel and then, without technical programming, allows the model to be dynamically applied to the portfolio or to a sub-set of the portfolio.

SmartCalculations can be simple calculations deriving values from an arithmetic formula or factor table, or can be significandy more complex calculations in respect of factors such as unexpected loss or marginal risk.

SmartSentinels'

Portfolios are dynamic and can be affected every day by a variety of fundamental factors which could adversely affect the Bank's profitability and decision making. Most Bank's can see the effects of changes to credit ratings, cost of funds and rapid draw-downs only on a periodic basis, usually on a reporting cycle for limits or on an ad hoc report following an alert from some quarter of the Bank. ^{• ■} . . . = •. . ^■

SmartSentinels can be seen as a corollary to SmartCalculations, in that they can be associated with a particular level in a hierarchy or more specifically to a particular node within a hierarchy, such as a geographical territory. Instead of providing a calculation which is initiated by the user, SmartSentinels are initiated by a condition at that level or node in the hierarchy, such as the total exposure exceeding a predetermined value or credit limit within a relationship or within a whole industry. SmartSentinels therefore allow users to mount triggers or automatic alerts on Obligors, Facilities, Countries, Industries or any other user- defined groupings which trigger on any user defined condition, such as the breach of a limit or other comparative performance measure.

Using SmartSentinels, a user can thus keep track of a larger number of potential alert conditions including limits placed on user-defined concentration groupings, groups of industries or regions, giving warnings as soon as conditions are reached such as sudden draw-downs from authorized amounts. At the software level, SmartSentinels are implemented by writing 'triggers' within the database that then 'fire' routines at the front-end to alert the user to the fact that a limit or condition has been satisfied or has been breached.

Using the system of the invention, users can navigate readily into the data, drilling down using a wise variety of parameters and categories (eg by industry, region, size, products, etc, as well as by result categories such as by capital utilisation) . This allows users to readily access data needed to identify concentration or weak areas within the loan portfolio.

SmartCalculations and SmartSentinels can be mounted on specific nodes within any user- defined hierarchy, so that they act on a particular country, industry or concentration grouping and all the facilities within that node. SmartCalculations can also be used to either cumulate results up or distribute down these results at each level utilising user-defined calculations or methods of distributing values between sub-nodes.

In addition, OLAP Hierarchies can usually be only constructed with regard to known predetermined parameters such as locations, products, customer categories etc. While this capability is suitable for monitoring marketing or production data it misses some major requirements for portfolio management.

Many concentration groupings of obligors are multiple levels deep and based on cross- ownerships, partnerships or business dependency that do not necessarily fit into any given parameter groupings .

Users therefore need to be able to construct hierarchies of multiple levels of depth, based on nothing more than user-defined parent-child relationships, representing business risk, joint ownership or other ad hoc concentration groupings. This does not therefore fit within current capabilities of OLAP technology.

Sector Stress Testing

Users need to see not only the current effects of changes within their portfolio, but also the effects of envisaged changes in dynamics such as cost of funds, mass credit migrations and proposed hedging. In order to achieve this, key calculations and models can be re-run iteratively with a number of changing parameter values.

Sector Stress Testing may include taking a calculation such as for PoD or RARoC and re- running it iteratively, changing one or more underlying parameters such as Credit Risk Ratings, Interest Rates, expected usage and loss recovery rates.

Outputs of stress testing can be viewed at a macro level or detail level within a grouping such as each obligor within and industry or each industry within a country, allowing users to successively drill-down on detail levels including regions, industries and individual obligors.

Because more than one dynamic may come into play at any one time it may also be useful to iterate multiple parameters simultaneously. For instance a change in currency or interest rates, at the same time as changes in credit risk migrations within a region or industry, showing the resultant effect on RARoC or capital utilisation, can be seen combinationally and viewed as a 'Landscape Graph'.

SmartCalculations including basic calculations like PoD, LGD and Unexpected Loss can be used within this stress-testing.

The SmartCalculations engine automatically integrates with existing Portfolio Management Systems such as Moodys KMV, RMGs Credit Manager, Credit Risk Plus, as well as default models including external models like Moodys/KMV and Risk Grades and internal models for particular regions, sizes of obligor, or industries. Users can define their own hierarchies based on parameters which include result-bandings such as EDF or RAROC groupings. These can be used for SmartCalculations and for sector based stress-testing, for instance creating a SmartCalculation to isolate those obligors with the most deteriorating EDFs or fastest draw-downs from authorised a mounts. Then a separate SmartCalculation such as the Marginal Risk contribution can iteratively model the effects of hedging or buying credit protection different proportions of the group of loans. The results of the stress testing can be to place alerts or new limits on these concentration groups.

The system,, provides a graphical user interface interlinking users to allow trading. An example of the graphical user interface of the Credit Trade Portal is illustrated in Fig. 2. This type of combined user interface 20 is accessible to both buyers and sellers, allowing users to find appropriate counterparties. The interface includes user's current portfolio window 21, a trade scenario window 22, displaying loans with the user is offering for trading, a counterparty portfolio window 24 (showing the 'universe' of counterparty trading portfolios), a negotiation window 26 showing counterparty loans currendy offered for trading, and enabling the isolation of a selected buy, a trading scenario detail window 23, in which the user can immediately gauge the impact of a trade within their current portfolio, and a selected buy detail window 25 showing details of the selected buy from window 26.

The user can 'drag and drop' potential buys from negotiation window 26 into trade scenario window 22, which has the effect of transferring a large number of datapoints (typically 15-30, including attributes such as limit, maturity, product type, drawn amount, collaterals, cashflow schedules, etc) . The trading scenario detail from such a potential buy are presented in window 23. Using this portal, users can price a loan from the information supplied via the exchange just as if they were originating the loans themselves. Such information includes the obligator's external ratings, the loan product being traded, cashflows, industry geographic weightings, expected usage rates, seniority, and associated collaterals. This underlying data can be adjusted by the prospective buyer during their pricing review of the loan, to include subjective factors such as recovery rates, expected usage and ultimate risk/concentration risk. Such adjustment can be made on the basis of the buyer's own assumptions and calibrations based on underlying data such as concentration groupings for the obligor, the product and collated types.

De-identification and Confidentiality

Protection of confidential information of the obligor is a key issue for many banks who hold relationships with these obligors. Credit Trade Portal allows the initial pricing may be done without the name by using an encoded identifier but the external ratings and market prices can be delivered. If the purchaser is then sufficiently interested they can then - under appropriate terms - be provided ^■with the names, at which point they can apply their own internal ratings to it.

There is therefore a two stage process in the bid and acceptance process, comparable to a 'half bid' or 'contingency offer'. In the absence of other considerations, this would be the offer for the loan. 'Gating factors' such as types of loans or certain names can also be applied in the initial stage before the name is identified and detail assessment pricing is undertaken.

The invention therefore allows a seller to control access to confidential information with regard to other participants in the marketplace, keeping selected attributes secure or de- identified. The system thus provides the functionality of individually turning off access to any pricing attribute, until the counterparty has provided appropriate information (such as identification, and execution of confidentiality undertakings with regard to the attributes) . The system includes reconfigurable 'de-identifying classes' allowing selection of this functionality for groups (eg by country, by industry, or by size) . This security capability is also built into the messaging format for exchanging information, and thus works in conjunction with the common database and data model (s).

Detailed Assessment and Pricing

Once the initial match between the counterparties has been made and the loans selected for purchase or sale, each loan component can be accessed in more detail by the buyer.

The loan details that can be presented to the potential buyer are downloaded directly into the Portfolio Insight tool with necessary de-identification of critical data.

The sample screen shots of Figures 3, 4, 5 and 6 show facilities as follows:

Obligor screen (Fig. 3)

The obligor's risk rating can be derived from external sources (such as Moody's Risk Calc). After identification it can be re-rated against the bank's internal rating system. Within the system, the borrower's identity can be inserted into an existing sub-portfolio of similar borrowers (by industry, region, etc), for comparison and calculation of sub-portfolio returns.

Obligor Facility > Credit Facility > Cashflow Output screen (Fig. 4)

This function, also de-identified, includes cashflows. These can be very complex and highly customised and can include dead-periods, periods of negative amortisation, etc. These cashflows are used to calculate risk adjusted returns from the loan within the buyer's own portfolio.

Obligor Facility > Credit Facility > Collateral screen (Fig. 5)

All collaterals are detailed for the facility and can be separately assessed by the buyer for their estimates of recovery and LGD.

This function details the collaterals for each facility including the coverage and expected recovery rates. These can be amended by buyers to recalibrate their valuation of the loan.

Results screen (Fig. 6)

Results can be shown for the proposed purchase, calculated as if the loan had originated direcdy into the bank's portfolio, using the same ratings, assumptions as to collateral recovery and capital model as for other bank - originated loans, thus giving the buyer full control and knowledge of the asset being considered.

The system interface includes a trading screen as illustrated in Figure 7, which is discussed in further detail below.

The mechanism of the loan pricing and trading system of the invention addresses the key issues in respect of transparency, client confidentiality, and maintaining anonymity in the market. User of the system can therefore gain access to the essential data about the names they are buying, the terms, covenants, seniority of the debt etc to make an accurate assessment whilst they themselves can maintain the confidentiality of sensitive or proprietary information about their clients and obligors (their exposure to them, estimates of loss given default, internal ratings of credit performance, etc) .

The basis of the data exchange is a standard message format for communicating all relevant information between parties in the loan trading environment. This embodiment utilises a specially developed protocol referred to as Financial Trading Markup Language (FTML), which is designed to be able to communicate all relevant loan attribute data between parties, as well as trading requests, underlying parameters (such as document classifications), and even underlying valuation models. The FTML messages employ so-called 'metadata' (data that describes data, such as field and entity definitions), in order to create the necessary structures in the counterparty's database during an interaction. As explained above, different institutions and different industries employ different means of parameter classification, and FTML provides a mechanism whereby the relevant data can be readily 'translated' between them under mutually consistent definitions, dynamically and bilaterally. As a user begins carrying out a search for trades, the system automatically creates the FTML statement which will be transmitted via the message handler to the other party when a potential deal is selected.

Figure 8 illustrates schematically a process of data transfer using FTML in the pricing analysis taking place between two parties. The same reference numerals as used in respect of Figure 1 are used to refer to similar components. Each party's site is associated with an FTML message handler 30, 31 enabling the two-way communication of loan information and trading requests, whilst a generated FTML message is illustrated at 36., In using the system, a ^{■ ■ '•} database of offered loans 32, 33 and desired purchases 34, 35 is' associated with each party's site. Each FTML message 36 is translated by the respective FTML message handler 30, 31 to a request to select loan data from registered business objects at the respective counterparty site. FTML messages 36 also serve to transmit common classifications (metadata defining key data attributes) bilaterally between trading parties (changing their metadata structure) to provide consistent definitions for trading between those parties in the future. A metadata descriptor message (encapsulating the obligor and loan attributes) includes a metadata interpreter message, to enable the data interpretation for use with different party systems. By using metadata interpreter objects, metadata descriptors can be translated from the sender system interpretation to the receiver system interpretation, allowing data provided by one party to be effectively 'unbundled', ie localised to the counterparty's model and user interface, for presentation to the counterparty. For example, an attribute on a first party system "Loan Equivalent Value" within a category "Collaterals" is interpreted to a counterparty system as "Maximum Exposure" within a category "Mortgage Asset".

Central debt exchange 15 serves to authorise users accessing the system and to monitor trades between counterparties. Figures 9a, 9b further illustrate the process flow of the method of the invention, and provide further detail with respect to the FTML message generation and exchange as part of this flow. The left hand side of the flow diagram depicts FTML handling taking place on a party's computer system, whilst the right hand side depicts FTML handling taking place on the counterparty's computer system, with messaging exchanges taking place between the systems. The pricing of loans between parties can be based on a number of different models, including:

^■ 'relative pricing' models for valuation of a loan in accordance with the relative value within each party's portfolio and based on internal models used by both parties, such as 'risk adjusted return on capital' (RAROC), and 'return on equity' (ROE), based on the risk and value effect on that party's portfolio and company equity.

^■ market pricing models based on current trades and bids in the marketplace for either that loan or equivalents (such as syndicated loans or repeated loans to large corporations), or for similar loans made to equivalent obligors.

^■ 'mark-to-market pricing', based on pricing for comparable sources of financing for such an obligor within the marketplace.

^■ portfolio-based economic pricing models, such as KMVs 'Portfolio Manager', Risk Metrics Group's 'Credit Metrics', or CSFB's 'Credit Risk Plus', assessing the concentration risk based on a number of correlation methodologies and the unexpected loss that would occur should a number of risk correlated loans within the portfolio default in unison. The measure of unexpected loss is measured from a probability distribution of average loss from the portfolio moving out by a selected number of standard deviations from that average up to the 99th percentile (the potential 'one day in a hundred') at the edge of the probability distribution curve. In the case of a diversified portfolio the area underneath the remaining tail portion will be small whereas in the case of a portfolio with strong risk concentrations this unexpected loss may be relatively large. Debt trading provides a mechanism of reducing the unexpected loss and the reserve capital required by the party.

The skilled reader will appreciate that the present invention is not limited to any particular portfolio or pricing model, the particular method of valuation that may be selected depending on many factors. Indeed, each product will be associated with a different set of attributes and may require a different pricing model.

In accordance with the invention, a bank does not have to part with any proprietary or confidential information about the loan assets other than to the buyer and as reasonably required by the buyer to make an assessment as to quality and value, such information being transferred in an encrypted format for security. The trading exchange maintains confidential information such as a bank's current holdings, buying/selling history, current bids, sales and purchases. With respect to the trading step, the system of the invention allows associated documentation to be transferred electronically, so that brokers can complete the trade as an integral part of the process, generally through an outsourcing of the documentation review, due diligence and setdement to a trusted third party service. The system facilitates this process by monitoring the electronic transfer of the documentation to and from the review parties.

Two ways in which the system may be implemented and accessed by participating banks are an internal standalone system with the bank's Intranet, or an external ASP system through a third party provider.

Features of the debt exchange system of the invention include some or all of the following:

1. Credit Trade Portal, the intelligent trading engine interface, described above, which allows counterparties to price the corresponding names and credit exposures with regard to two models using data from their current portfolio and capital models and data from the exchange: a. 'Relative Pricing' Model - based on their own portfolio and the portfolio of their counterparty (including the calculation of the marginal risk contributions within the counterparty's portfolio, unexpected loss and relief from credit capital due to the diversifiable risk component. b. 'Mark-to-Market' Pricing Model (described below) — based on bids and offers and analytics of deals on the exchange for that type of loan being offered in the wider market place. c. Local Database of loans being offered for trade by the user and imported data of loans being offered by counterparties.

2. Mark-to-Market pricing (MMP) model built exclusively on the trades and data from the Debt Exchange and proprietary pricing analytics exclusive to participants on this exchange. The MMP model is then able to give daily 'mark-to-market' valuations of the participant's existing loans with their portfolio, as well as pricing for potential deals in negotiation.

3. Central Database of available names and exposures on offer and the names of the exchange participants, Moodys-KMV credit ratings and pricing models based on both credit risk and market models, updated in real-time. Names and exposures are de- identified and classified according standard categories for Collateral, UGD, Industry code etc. 4. Central Exchange Engine for optimising the selection of candidates for potential trades the exchange will, from the universe of participants and their published credit exposures, find and disseminate potential credit swaps in order to maximise the diversification between the participants. The automated match-making function will, from their published exposures and weightings in the database, bring counterparties parties together and actively suggest trades of baskets of names or credit derivatives in order to reduce each counterparty's use of credit risk capital. The candidate trades will be the initial point in the workflow process to affect the trades.

5. Workflow engine for optimising the contractual interaction between counterparties for exchanging names or credit derivatives based on standard documentation such as the ISDA standards for credit swaps. Based on the emerging Financial XML standards and B2B technologies, counterparties are able to dynamically set-up transactional relationships for trading names credit swaps via the Web interface, and then automatically transfer the information and data between their underlying loan systems and databases.

6. Access provision to the service from trading screens (such as Bloomberg, Reuters), also via the Web, using proprietary trading desk protocols such as FIX. The available trades designated as 'public' from individual party trading screens can be uploaded to public services (such as Reuters, Telerate Moneyline and Bloomberg), byway of which the respective parties can also receive bids for loans being offered from the wider investor and credit markets.

The optimisation of a trade or set of trades between parties as discussed above can be carried out through the implementation of a variety of different algorithms or 'analytics models'. Suitable models include the following: Portfolio Management Model. This algorithm assesses concentration risk and economic capital based on a loss distribution. It combines elements of the known Credit Risk Plus, KMV's Portfolio Manager, and Risk Metrics 'Credit Metrics' models. In this way, it assesses the concentration risk component of exposures and the marginal risk contribution by a use of a combination of different approaches to correlation and risk contribution.

Bilateral Portfolio Selection Model. This algorithm assesses concentration risk and economic capital based two portfolios, and selects the optimal trades between them. It optimises against two portfolios and selects the optimal trades between a set of offered loans and the counterparty's portfolio. The model iteratively adds the potential trades into to counterparty portfolio and finds the selection that would provide the greatest relief of concentration risk. The model works in both directions and finds a trade amount that can be equally traded in both directions as an exchange trade.

5 Multiple Party Trade Optimizer Model. This algorithm selects the best combination of trades between multiple parties and multiple portfolios. Loans on offer are pooled and then re-allocated to the portfolios using a trade optimizer model and based on one continuous trade between all parties. This model is an extension of the above Bilateral model to embrace multiple portfolios and participants in a 10 single trade. With regard to each participant, the model selects from the 'pool' of available trades amongst the group, finding between the participants the optimum overall blend of trades between that group. This therefore enables trading groups to determine the optimum reallocation of exposures within their portfolios to create - ' ^: . ^••^{• ■}- ^• -^• maximum diversification and minimum concentrations. The net effect is similar to 15 that which would result- from a merger of all of the participant portfolios into one single portfolio, with each participant retaining the same size of individual portfolio.

Securitization Factory Model. This algorithm selects the best combination of trades from loans from those on offer in the market for the Collateralised Debt Obligations (CDOs) currently being securitised. Multiple portfolios from all the participants in

20 the market are created, allocating available loans to CDO securitisation vehicles built on a production. The model's 'allocator' finds the optimum loans to provide a diversified security made up of a group of loans with the minimum risk concentrations and maximum investment returns from the cash-flows. The model allocates and build CDOs and instruments in a continuous production line process

25 driven by parameters for the securities (size, constraints, make-up) and the availability of loans in the overall market place.

The screen of the system interface, illustrated in Figure 7, allows potential trades to be bidded on by both parties interactively, based on their own internal valuations. Loans can be dragged by a party from a counterparty's portfolio window into the party's local portfolio 30 scenario window. This initiates the transfer of the data points (between, say, 15 and 40 different data points) required to price the loan by the party.

As mentioned above, the system includes a dynamic program module configured to find an optimum fit of loans to be traded between two or more parties based on current portfolio concentrations, in order to mutually diversify their portfolios. The module can be set to automatically search current bid and offer prices for loans, as well as the parties' existing portfolios, to identify such opportunities to optimise diversification.

The exchange provides a standardised process whereby the credit risk component of the loan assets can be moved off balance sheet and traded through the issuance of credit risk derivatives (CDS, CDO, CLO) against the respective members' loan portfolios. Securitisation vehicles such as CDOs (Collateralised Debt Obligations) or funds of loan assets or derivatives which are based on special purpose vehicles (SPVs) can be further decomposed or 'tranched' into levels of loan-assets by risk, and the risk on individual tranches traded separately.

The above credit risk derivatives an be exchange-listed only if key listing requirements are satisfied. The use of common standards disclosure, common documentation and a set of known, standardised securities facilitates an environment for observable market pricing to exist. Trading of credit risk derivatives yields observable market risk premiums for key risk characteristics.

The exchange also provides a mechanism for trading loan assets that are already sεcuritised • via special purpose vehicles (funds for investing in loan assets), and investment funds. The , exchange can also serve as a clearing house counterparty for all loan assets securitised through the exchange. The system provides the service of optimising underlying loan portfolio construction based on risk and cashflow characteristics.

As explained above, pricing a loan for prospective trading requires the exchange of a large number of loan attributes and data points. The system of the invention embraces common formatting and calibration of the attributes, the creation of new attributes which are relevant to the pricing of a lending product but for which there is not a pre-defined attribute, and the movement of complex data such as cash flow schedules, sets of associated collaterals, loan facilities with multiple underlying instruments, fee schedules, etc.

The invention, then, allows for the real-time exchange of the relevant pricing attributes between parties and their storage within a standard form of database and common data model, either residing at the buyer and seller locations, or on a third party exchange system. In accordance with confidentiality requirements, the data is viewable and editable for purposes of calibration and analysis.

Figure 10 illustrates diagrammaticaliy a suitable architecture of the credit portal of the system of the invention, showing the data tier, business tier and client tier (built on a .NET platform) . For enterprise scalability and deployment, the application is built on an Intranet/thin-client model, which allows a rich decision support interface whilst minimising the workstation footprint and thus the deployment overhead. As illustrated, the database features control and metadata tables, the identification of core and non core structures, generic structures and XML storage. The middle (business) tier is based on VSA (compiled or script) and compiled customised subclasses, whilst the client tier features a number of plug-in components and the metadata-driven graphical user interface. As underlying data structures are developed, new modules can readily be added without program modification as plug-ins within the existing framework.

Modifications and improvements to the invention will be readily apparent to those skilled in the art. Such modifications and improvements are intended to be within the scope of this invention.

Claims

Claims

1. A method for facilitating trading of debt instruments between parties via an electronic telecommunications network, each debt instrument comprising a set of debt instrument attributes including obligor information, debt instrument attributes of a plurality of debt instruments to be offered for sale via the electronic telecommunications network input by the parties into a database, the method including the steps of: a) accessing from a credit bureau dynamic borrower data related to said obligor information; b) calculating, for a party, pricings for the debt instruments, calculated from said debt instrument attributes and said dynamic borrower data; c) applying to the pricings a diversification factor based on criteria relating to risk exposure within said party's existing debt instrument portfolio; and d) selecting one or more debt instruments in accordance with a comparison of factored debt instrument pricings.

2. The method of claim 1, including the step of transferring data required to complete a debt instrument transfer to or from said party in accordance with said selection step to allow completion of a potential trade which has been accepted by the respective parties.

3. The method of claim 1 or claim 2, including the step of modelling the impact of a debt instrument transfer on the debt instrument portfolios of two prospective parties to the debt instrument transfer, the modelling step being carried out in accordance with the respective diversification factors of both parties, the selection step carried out in accordance with the result of said modelling step in order to ensure mutual diversification of debt instrument portfolios between the parties.

4. The method of claim 3, the modelling step being carried out on the basis of localising debt instruments in accordance with common attributes, to enable analysis on the basis of one or more groupings, such as industry or geographical region groupings.

5. The method of any preceding claim, wherein step (b) involves calculating pricings on the basis of relative pricings of the respective debt instruments between the parties, in accordance with the relative value of prospective trades in those debt instruments as between the parties.

6. The method of any one of claims 1 to 4, wherein step (b) involves calculating pricings on a mark-to-market basis, in accordance with the value of the debt instruments relative to other similar instruments available on the wider credit market.

7. The method of any preceding claim, including the step of accessing captured data relating to the price of offers, bids and/or executed trades of debt instruments to provide information to the value of debt instruments available on the wider credit market.

8. The method of any preceding claim, whereby the debt instrument attributes are transferred in a common format in the form of metadata definitions, allowing one party using one portfolio management system to interpret debt instrument attributes provided by a party using a different portfolio management system.

9. The method of claim 8, said metadata definitions based on a Financial Trading Markup Language (FTML) protocol.

10. The method of claim 8 or claim 9, including the steps of a party inputting one or more definitions of new debt instrument attributes not currendy defined between said parties; and transferring said one or more definitions to another party, in order to dynamically enhance the range of debt instrument attributes.

11. The method of any preceding claim, wherein the debt instrument attributes are selected from the group including: obligor information; maturity/tenor of debt instrument; coupon and yield; commitment amount; current drawn amount; probability of default (PD) of the obligor and/or of the debt instrument; volatility of PD; status of the debt instrument(ie funded or unfunded); cashflow and payment schedule; collateral information; estimated recovery rate in case of default; interest rate spread information; fees applicable to the debt instrument; and price including discount or premium information.

12. The method of any preceding claim, wherein each party has or employs an internal computer system for managing that party's debt instrument portfolio, the method carried out via the provision of a common database for inputting debt instrument attributes in a common format provided by each party by way of their respective portfolio management systems.

13- The method of claim 2, wherein the step of transferring a debt instrument is carried out by direct bilateral exchange of data between the parties.

14. The method of claim 2, wherein the step of transferring a debt instrument is carried out by way of a debt exchange intermediary.

15. The method of any preceding claim, wherein specified debt instrument attributes input by a party into said database available for use in said calculating step are not made directly accessible to other parties.

16. The method of claim 15, wherein the system is configured to suppress identification of one party to other parties.

17. A computer-based system for facilitating trading of debt instruments between parties via an electronic telecommunications network, each debt instrument comprising a set of debt instrument attributes, the system including: a logical unit configured to allow input of debt instrument attributes of a plurality of debt instruments via the electronic telecommunications network into a database in a common format, the debt instrument attributes including obligor information; a logical unit configured to access from a credit bureau dynamic borrower data related to the obligor information; a logical unit configured to calculate, for a party, pricings for the debt instruments, calculated from said debt instrument attributes and said dynamic borrower data; a logical unit configured to apply to the pricings a diversification factor based on criteria relating to risk exposure within said party's existing debt instrument portfolio; and a logical unit configured to allow selection a debt instrument in accordance with a comparison of factored debt instrument pricings.

18. The system of claim 17, including a debt exchange interface to enable the transfer of data required to complete a debt instrument transfer between parties, so to allow completion of a potential trade which has been accepted by the respective parties.

19. The system of claim 17 or claim 18, including a logical unit configured to model the impact of a debt instrument transfer on the debt instrument portfolios of two prospective parties to the debt instrument transfer, the modelling being carried out in accordance with the respective diversification factors of both parties; wherein the a logical unit configured to allow selection a debt instrument is adapted to make such selection in accordance with the result of said modelling, in order to facilitate mutual diversification of debt instrument portfolios between the parties.

20. The system of claim 19, the logical unit configured to carry out the modelling on the basis of localising debt instruments in accordance with common attributes, to enable analysis on the basis of one or more groupings, such as industry or geographical region groupings.

21. The system of any one of claims 17 to 20, including a data interface configured to allow transfer of the debt instrument attributes in the form of metadata definitions, allowing one party using one portfolio management system to interpret debt instrument attributes provided by a party using a different portfolio management system.

22. The system of any one of claims 17 to 21, including a common database configured to enable input of debt instrument attributes in a common format provided by each party's respective portfolio management system.

23. The system of claim 18, including a computer system separate from the control of the parties themselves, configured to provide a debt exchange intermediary to facilitate transferring a debt instrument between the parties.