All -

Our challenge for the next few months is to build an automated system to 
provide differential pricing on thousands of credits [5,000 by year-end]. 
Most of these credits will be illiquid in terms of market price information, 
making the challenge harder, and the end result more important in terms of 
competitive pricing advantage. What we need is an overall strategy for how we 
plan to achieve this from the quantitative perspective.

Currently we have several models for credit pricing either in use or under 
development:
FMC Model (default probability approach). Using Bloomberg's Fair Market (par 
yield) Curves, probabilities are generated from the risky-LIBOR, then 
default/bankruptcy swap prices computed using expectation methodology.
FMC Model (credit spread approach). Using the FMCs, then directly taking the 
LIBOR credit spread at each tenor, adjusting for basis and compounding 
differences.
Bond Model (FMC approach). Taking the FMCs as benchmark curves, the model 
regresses the input bonds (specific to a name) on the two best fitting 
benchmarks. The result is a zero yield curve with the same shape as the FMCs, 
but with the level tweaked for the specific issuer. Prices are then generated 
using both spread and probability approaches. Under testing.
Bond Model (spline approach). Taking only the bonds specific to an issuer, 
the model fits an exponential cubic spline to the zero-coupon price curve, 
then builds a zero yield curve from this. Under testing.
Market Prices. For certain liquid names, or sectors/ratings, CDS market 
prices are used, then recovery and event discount used to get bankruptcy swap 
prices.
KMV. Using Expected Default Frequencies (EDFs) from the KMV model and 
database, we will build a model to price default swaps, making appropriate 
risk adjustments. KMV is being installed now, so model will be worked on next.

Each of these models returns a price (credit default and bankruptcy), and the 
accuracy of the price depends on many factors - liquidity and regulatory 
differences between bond and CDS markets, recovery assumptions, risk premia, 
capital charges, etc. The aim will be to accurately price as many liquid 
names as possible, based upon these models, then use these prices, alongside 
other financial information, as the backbone to a full automated pricing 
system. 

Our inputs to the proposed pricing system for a specific name are model and 
market prices for all issuers, alongside name-specific 'soft' data from 
credit reports and financial statements. If the credit is liquid enough, a 
price will be generated from their own information only. Otherwise, the 
credit will be mapped onto a subset of liquid credits, with financial 
information and historical price movements providing the mapping and weights. 
The model price will then be periodically adjusted to align itself with 
market (or trader) prices, and this adjustment will feed back into the 
weighting and mapping composition. In loose terms, we could think of the 
system price for an illiquid credit as being a weighted average of liquid 
market prices (bonds, equities, default swaps), where the weightings are 
calibrated using credit analysis, financial ratios, etc.

The key steps to implementing such a system will be:
Establishing what exactly we want to 'predict' - is it a price, a rating, a 
probability, or a score? We will need a clean market history to calibrate to, 
which we only really have for ratings. We will then need to develop a mapping 
from rating/score to price.
Getting and cleaning the historical financial and credit data required to 
calibrate the model.
Building the mechanics of the model, ie, the calibration methodology. Neural 
nets/fuzzy logic seem the obvious candidates, but which exact methods and 
software packages to use?
Determining an automated methodology for mapping names with limited 
information into the model.
Getting the "true" market price, in order to feed back an error. At present 
such a price exists for very few credits.
Allocating resources to the development. McKinsey claimed such a system would 
take 6-10 man-months to develop.

Further ideas or comments are requested, as we need to develop our strategy 
asap. The model description above is fairly vague, as we don't yet have the 
knowledge needed to fill in the specific details. Further help will be 
especially required on this if we are to continue to move at 'internet speed'.

Regards

Ben