As many of you know, Financial Network Analyzer is the program that I have been developing for the past year and a half. Its currently mainly used by central banks for the analysis of financial microdata and for the simulation of payment systems.

After major rewrite of much of the application and thorough testing, FNA 1.3 is finally available. Its still in “beta” but most of it should work quite nicely already. Let me know if you try it and encounter any trouble. The program has three major components: financial network analysis, tools for working with large CSV based datasets, and a payment systems simulator.

The most important improvement, however, is the Manual with plenty of examples for each command that should enable users to quickly jump into using the program. The program now also has its own website and blog at financialnetworkanalyzer.com. The program’s blog will be the main source of updates on the program while this blog will continue to focus on financial network research.

A recent article in FNA blog looks into the visualization of financial networks. Visualisations will be the major update for the next version of FNA for which work has already started. The other major change is that version 2.0 will move FNA into a client-server architecture allowing a more scalable environment for large-scale modeling and simulations. You can browse the specifications for more details.

A new paper by Farooq Akram and Casper Christophersen entitled “Interbank overnight interest rates – gains from systemic importance” analyses the Norwegian overnight interbank interest rates paid by banks. They find that during the Financial crisis, the interest rates were substantially below indicative quotes of interest rates provided by major banks. The interest rate variation is explained by the relative size and connectedness of the banks, implying favorable terms for banks of systemic importance.

Moreover, interest rates are found to depend not only on overall liquidity in the interbank market, but possibly on its distribution among banks as well, suggesting exploitation of market power by banks with surplus liquidity. They also find evidence of stronger effects on interest rates of systemic importance, credit ratings and liquidity demand and supply since the start of the current financial crisis.

An open-source implementation of the algorithm for uncovering the interbank loans was developed as part of this project. The algorithm is available as part of the Financial Network Analyzer.

After a little over a month of development, beta version 1.0 of the tool is now ready. It is an open source project sponsored by Norges Bank. The code is available at Google Code (get in touch with me to participate) and the documentation on Google docs. Currently the tool has a command line user interface and its main features include:

• Construction of networks from payment/trade data where an arc (link) is established if a payment/trade takes place between the banks. Further payments/trades add to the weight of the arc. Aggregation interval can be based on the number of payments/trades, on their value or on their timing (e.g. daily networks)
• The networks generated can be edited (transposed, made symmetric) and vertices (nodes) can be dropped based on any of their properties that are calculated (e.g. all nodes without outgoing links or smaller than some threshold value)
• A number of statistics can be calculated for the vertices and arcs, e.g. betweenness centrality, random walk betweenness, eigenvector centrality, PageRank, HITS, average shortest paths, reciprocity, eccentricity, strength, loops and degree. Strong and weak components of the network can be identified.
• Networks, vertices and arcs and their properties can be viewed on screen
• Networks can be saved as vertex/arclists or in Pajek format to f ile for further analysis.

To install the tool simply download the latest version and copy the contents of the .zip file to some directory. You start the program from start.bat. You can try that it works by typing:

run -file data/script.txt

it runs script.txt file (in /data folder) which contains some commands to build and analyze networks created from example data (also under the /data folder). Please let me know of any bugs or needs for improvement.

For other similar tools, see the Social network analysis software article on wikipedia

I started a project with Norges Bank to develop an easy and comprehensive tool specifically geared towards creating and analysing financial networks constructed of trade or payment data. Its is an open source project and the program and code will be available at fna.sourceforge.net already during the development phase. The first phase of development for a command line utility is expected to be completed within this year. Specifications for the project are available as a Google document. All feedback and contributions to the project are welcomed.

The Receipt Reactive Gross Settlement (RRGS) method was proposed by Jamie McAndrews in Johnson-McAndrews and Soramaki (2004) as a new, incentive compatible liquidity saving mechanism. The basic idea of RRGS is that banks are sure to use only incoming funds to settle their less urgent payments. Each bank has the incentive to submit payments to the RRGS queue as costly liquidity is consumed only when the bank receives funds from other banks.

This simulator allows simulations of one version of RRGS with historical payment data. It is easy to use and efficient, being able to simulate a day with half a million payments in less than 60 seconds. The fast speed of the simulations and quick set-up allows one to test many alternative scenarios easily.

Read the rest of the entry for instructions on downloading and using this application. You are welcome to get in touch with me for any questions.

Input files

Payment data file

The data must have the following fields in the following order: id, date, time, value, sender, receiver, priority. NOTE: payments must be ordered ascending by date and time. The file can contain multiple days of data. If the time field is shorter than the expected format, a leading zero is added to the beginning (e.g. to fix a time string 55959 to 055959 – one second to 6am). The priority must be 1 (high) or 2 (low). The field and decimal separators used in the file are defined in Input parameters.

Funds data file

The data must have the following fields in the following order: date, bank, balance. The ‘bank’ field must match the ’sender’ and ‘receiver’ fields in the payment data. It must be ordered by date. A balance is used for subsequent days until a new balance is defined in the file. The field and decimal separators used in the file are defined in Input parameters.

Input parameters

• ‘Payments file’: Select the file with the payment data
• ‘Funds file’: Select the file with the opening balances for each day.
• ‘Overdrafts file’: Select the file with overdraft limits per bank for each day. A value of e.g. 100 means that the balance of the bank can go up to -100.
• ‘Date format’: date format in both Payment data and Funds data files, see possible formats.
• ‘Time format’: time format used in ‘Payment data file’, see possible formats.
• ‘Opening time’: Opening time of the system. The simulator will throw an error in case payments before opening time are encountered. Format as given by ‘Time format’.
• ‘Closing time’: Closing time of the system. The simulator will throw an error in case payments after closing time are encountered. Format as given by ‘Time format’.
• ‘Do queue optimization’: Optimizes the RTGS queue (if ‘Settlement method’ = RTGS) and RRGS queue (if ‘Settlement method’ = RRGS).
• ‘Allow negative balance’: Allows balance in RTGS or RRGS to become negative.
• ‘Settlement method’: RTGS or RRGS, see above.
• ‘Splitting method’: ‘Threshold’ refers to value above which payments are split into equal sizes each under the given threshold value. ‘Liquidity’ method will split the original payment into two: one worth the available liquidity by the bank, and one worth the rest of the value. In both methods payments are split only if liquidity for settling them in whole is not available. In ‘liquidity’ method the liquidity available must also be above the minimum value given as a parameter.
• ‘Field separator’: field separator used in Payments and Rates files, usually ‘;’ or ‘,’
• ‘Decimal separator’: decimal separator used in Payments and Rates files, usually ‘,’ or ‘.’
• ‘Load parameters’ and ‘Save parameters’: loads/saves parameters onscreen from/to a file

Operation

1) Settlement by RTGS

In RTGS settlement a payment is settled immediately if there are sufficient funds. In case there are not sufficient funds to cover the payment, the payment is queued – and released immediately as sufficient funds become available from incoming payments. The RTGS balance is reduced by outgoing payments, and increased by incoming payments.

2) Settlement by RRGS

In RRGS payments marked with priority 1 are settled immediately, irrespective of available liquidity. Payments marked with priority 2 are settled by RRGS against the balance in RRGS. The RRGS balance is reduced by outgoing priority 2 payments, and increased by incoming priority 1 and priority 2 payments.

3) Queue optimization

The queue optimization is run at the defined intervals. Any payments submitted at that time are settled before the optimization is run. An optimization is run before end of day procedures are begun. Queue optimization can be used to optimize either the RTGS queue, or the RRGS queue. Optimization is done according to algorithm in Bech and Soramaki (2001).

4) Splitting

When a payment is split the elements to be queued are put in the queue before the payment that can be processes is settled. This way a chain of events can cause the immediate settlement of the queued parts as well. For details of splitting, see Leinonen and Soramaki (2001).

5) End of day procedures

In end of day procedures all pending payments are settled not taking into account any constraints.

Output

-out.txt contains statistics on all individual payments

• [the same fields as in the input data]
• ’settlement_time’: time the payment was settled
• ‘delay’: (in seconds)
• ’senderbalance’: balance of sending bank after settlement of payment
• ‘receiverbalance’: balance of receiving bank after settlement of payment
• ‘bilateralbalance’: bilateral balance from sender’s perspective (positive if received more than sent)
• ’settlement_method’: method by which the payment was settled: rrgs (immediately by RRGS), rtgs (immediately by RTGS), rrgs_queue (released from RRGS queue), rtgs_queue (released from RTGS queue), rrgs_opt (released by optimization algorithm from RRGS queue), rtgs_opt (released by optimization algorithm from RTGS queue), rtgs_eod (settled by end of day procedures from RTGS queue), rrgs_eod (settled in end of day procedures from RRGS queue)

-stat.txt contains statistics on each bank

• ‘day’: date
• ‘id’: bank id
• ‘value_as_recipient’: value of payments in input data where the bank is a receiver
• ‘number_as_recipient’: number of payments in input data where the bank is a receiver
• ‘value_as_sender’: value of payments in input data where the bank is a sender
• ‘number_as_sender’: number of payments in input data where the bank is a sender
• ‘number_submitted’: number of payments submitted for settlement
• ‘value_settled’: value of payments settled during the operation hours
• ‘number_settled’: number of payments settled during the operation hours. Due to split payments may be higher than number_submitted.
• ‘value_settled_eod’: value of payments settled in end of day procedures
• ‘number_settled_eod’: value of payments settled in end of day procedures. Due to split payments may be higher than number_submitted.
• ‘opening_balance’: balance at the beginning of the day
• ‘overdraft’: overdraft limit for the bank
• ‘minbalance’: minimum balance during the day (also including end-of-day procedures)
• ‘maxbalance’: maximum balance during the day (also including end-of-day procedures)
• ‘avgbalance’: average balance during the day
• ‘eod_balance’: end of -day balance
• ‘minbilateral’: minimum bilateral balance against across all other banks
• ‘maxbilateral’: maximum bilateral balance against across all other banks
• ‘avgsubmissiontime_received’: average submission time of payments received (unweighted)
• ‘avgsubmissiontime_sent’: average submission time of payments sent (unweighted)
• ‘avgsettletime_received’: average settlement time of payments received (unweighted)
• ‘avgsettletime_sent’: average settlement time of payments sent (unweighted)
• ‘avgsubmissiontime_received_weighted’: average submission time of payments received (weighted by value)
• ‘avgsubmissiontime_sent_weighted’: average submission time of payments sent (weighted by value)
• ‘avgsettletime_received_weighted’: average settlement time of payments received (weighted by value)
• ‘avgsettletime_sent_weighted’: average settlement time of payments sent (weighted by value)
• ‘avgdelay’: average delay for a delaying payments, sum of delays divided by the number of all payments. In seconds.
• ‘avgdelayweighted’: value weighed delay for a delaying payments, in seconds
• ‘maxqueuesize’: maximum number of queued payments at any given time
• ‘maxqueuevalue’: maximum value of queued payments at any given time
• ‘number_queued’: number of payments queued
• ‘value_queued’: value of payments queued
• ‘number_split’: number of payments split
• ‘generated_payments’: number of payments generated by splitting

Download, installation and running

Simply copy and extract this file (rrgssimulator1.3) to a folder that you create. Double click run.bat to launch the application. The package contains example files payments.txt, overdrafts.txt and funds.txt files (in the /data folder) and a parameters.txt file that you can load into the application and test the example data (change the paths to the correct files in the /data folder before starting the simulation).

Credits & Usage

I would like to thank John Jackson, Joanne McLafferty and Edward Denbee and Balazs Godeny for their contributions to specifying and implementing this application.

You are free to use the program for any purpose. The .zip file contains the source code as well. Please make a reference to this blog entry in case you use the application for any research.

(updated 29 October 2010 with version 1.3 of the software and updates to documentation)

In 1999 Craig Furfine published the article “Interbank exposures: quantifying the risk of contagion” (BIS Working paper, No. 70) where he for the first time used data on individual payments settled in the interbank payment system to construct a time series of the unsecured overnight loan market. The methodology has since been duplicated by numerous studies (see e.g. Bech and Atalay (2008), Bech and Rordam (2008), Iori et al. (2008), Wetherilt et al (2009) under “Links to research“) and is informally referred to as the “Furfine algorithm”. Loan data of this granularity is generally not available from other sources and the data sets generated with this algorithm can be used to e.g. analyze the topology and contagion in interbank markets. Also the recent crisis has made this type of data more desirable for financial stability and macroprudential supervision purposes (see earlier post).

At its simplest, the algorithm looks for two payments: first a payment of value v from bank A to bank B on day t, and second, a payment of value v + interest on day t+1 from bank B to bank A. As the interest rate may be unknown and due to the fact that some systems have hundreds of thousands of payments per day, random matches are also possible. To reduce such errors, a number of additional criteria can be used. The following small software application can be used to match trades of any length. The program has many additional filtering criteria that can be used.

Read the rest of the entry for instructions on downloading and using this application. You are welcome to get in touch with me for any questions.

Parameters

‘Payments file (Pass 1 input)’: location of the file with payment data. Fields must be in order: id, date, time, value, sender, receiver, [priority: optional]. The date format is defined below. The value field must be numeric and the sender and receiver fields must be integers. A line starting with # is considered a comment line. Empty lines are ignored.

‘Pass 2 input’: this file contains the trades identified by Pass 1 (see below), and is input for Pass 2.

‘Pass 3 input’: this file contains the trades identified by Pass 2 (see below), asn is input for Pass 3.

‘Run ID’: This run identifier is appended to result file names.

‘Define reference rates’: option to use reference rates (e.g. deposit rate or interbank rate). The algorithm will then search for trades that are within the given bounds (lower and upper) from this reference rate.

‘Rates file’: File for reference rates. Format: date, rate. (E.g. “1/1/2009, 5%”). A line starting with # is considered a comment line. Empty lines are ignored.

‘Date format’: date format in both Payments and Rates files, see possible formats.

‘Field separator’: field separator used in Payments and Rates files, usually “;” or “,”

‘Decimal separator’: decimal separator used in Payments and Rates files, usually “,” or “.”

‘Maximum duration’: the maximum length of overnight loans searched for. It is usually best to start with short durations and go for longer ones after shorter ones are established. For overnight loans, set to 1.

‘Trade value tick’: the “denomination” at which trades are made. Looks for round numbers such as 1.000 or 10.000 (only trades fully divisible by 1.000 or 10.000 are eligible)

‘Rate lower margin’: the margin setting together with the interest rate in the “Rates file” the lower bound for interest rates allowed, i.e. lower bound=’Daily interest rate in Rates file’ – ‘Rate lower margin’

‘Rate upper margin’: the margin setting together with the interest rate in the “Rates file” the upper bound for interest rates allowed, i.e. upper bound=’Daily interest rate in Rates file’ + ‘Rate upper margin’

‘Rate tick’: interest rates on overnight and term loans are often agreed in round numbers, e.g. 4.0% or 4.25%. This parameter filters out other possible trades. The unit is in basis points (100bp=1%).

‘Rate tick margin’: due to rounding errors the rate ticks are not always exactly as the Rate tick parameter would prescribe. This parameter allows you to set a tolerance around the rate tick. For example a tolerance of 1 would consider anything between 3.99% and 4.01% to be within the rate of 4.0%. The unit is in basis points (100bp=1%).

Operation

The applications looks for trades in three ‘passes’.

Pass 1 is a rough rule that identifies possible trade candidates which fulfill the following criteria:

• ’sender of advance’ = ‘receiver of return’ (advance is the payment made to deliver the loan to the borrower, and return is its repayment back to the lender)
• ‘date of return’ > ‘date of advance’
• ‘date of return’ <= ‘date of advance’ + ‘maximum duration’
• ‘value of return’ > ‘value of advance
• (’value of return’ / ‘value of advance’ – 1) * 365 / days <= ‘max rate’
• ‘value of advance’ is a round number as specified by value tick

Pass 2 filters the “candidates” according to the following criteria:

• Calculate ‘interest rate’s for possible trades in 1: ‘duration’ = ‘date of return’ – ‘date of advance’, ‘rate’ = ((1-’value of return’/'value of advance’)*365)/’duration’
• Calculate ‘lower bound’ and ‘upper bound’ for acceptable interest rates: ‘lower bound’ = ‘deposit rate’ – ‘Rate lower margin’, ‘upper bound’ = ‘deposit rate’ + ‘Rate upper margin’
• Select payments where: ‘interest rate’ is between ‘lower bound’ and ‘upper bound’ and ‘interest rate’ is with given ‘rate tick margin’ around the ‘rate tick’

Pass 3 selects the most likely loan from the possible ‘matches’ above by the following rules.

• In case multiple matches (1-many, many-1, many-many) select trade that has an interest rate closest to base rate on the date of the first leg. The rate is rounded to the closest rate tick before making this comparison.
• If the interest rate is the same for many trades then among these: in case 1-many relationship (1 advance is matched with many returns or vice versa), match latest advance and earliest repayment. In case many-many relationship, order advances and repayments and match them in order. Say there are M advances and N repayments. If M>N, then discard the (M-N) earliest advances. If M<N, then discard the (N-M) latest repayments. We now have equal-sized sets of advances and repayments. Match the payments in time order e.g. the earliest advance goes with the earliest repayment, the second goes with the second etc.

Output

The application creates three files (pass1_[run id], pass2_[run id], and pass3_[run id]) at selected locations:

• ‘advance_date’: date of advance (first leg)
• ‘return_date’: date of return (second leg)
• ’sender’: sender of advance / receiver of return
• ‘receiver’: receiver of advance / sender of return
• ‘advance_value’: value of advance payment
• ‘return_value’: value of return payment (advance value + interest)
• ‘advance_id’: id of payment (in input data) matched as an advance
• ‘return_id’: id of payment (in input data) matched as a return
• ‘advance_time’: time advance was made
• ‘return_time’: time return was made
• ‘loan term’: term of loan in calendar days
• ‘loan_term_business_days’: term loan in business days (e.g. Friday->Monday equals 1) –  a business day is defined as a day with at least one payment made)
• ‘rate’: interest rate in % (e.g. 4 equals 4%). This field is reported for Pass 2 and 3 only.

Download, installation and running

Simply copy and extract this Furfine-algorithm application to a folder that you create for it. Double click run.bat to launch the application. You need to have JRE1.5 installed (usually you do have it already). The package contains a file test-payments.txt and test-rates.txt files (in the /data folder) and an test-parameters.txt file that uses them. You can load that parameter file into the application and test the example data. It identifies one trade (in Pass 3) from the payments in the example.

Credits & Usage

I would like to thank Peter Zimmerman, Casper Chistophersen and Balazs Godeny for their contributions to this application.

You are free to use the program for any purpose. The .zip file contains the source code as well. Please make a reference to this blog entry in case you use the application for any written works.

As part of another project I revisited some Java code for developing genetic algorithms (GA). I had programmed them earlier as part of our Agent-based simulations where banks’ decision making evolved through the use of genetic algorithms. I decided to make the general purpose GA code available in case someone finds a use for it. The Javadoc and source files are available here. There is also an example for the iterated Prisoner’s Dilemma. I’m happy to answer any questions.