Skip to main content

Korean Lessons for the US, Part 2: Look the Other Way, It's for the Economy

In the previous post I pointed to some of the ways that financial regulators in Korea and the US have credibly committed to bad regulation by making themselves bad at collecting financial market information. But there were two unresolved issues I'll cover now:

  1. Why would regulators want weak regulation?

  2. How did Korea get out of this problem?

Answer 1: Sure, there are lots of reasons why regulators would want to have weak regulation. There are the usual stories about crony capitalism, revolving doors, etc. Sure, there probably is something to these theories. But there is also something less sinister, but more problematic going on:

loose regulation might be good for the general economy in the short-term.

In fact, this is how US regulators have been talking about the issue (for example see this great article from the FT). The basic argument is that enforcing tight capital adequacy requirements, lending standards, etc., makes less money and credit available to lend to businesses, people, etc. When businesses and people have less credit they spend less, economy tanks.

In 1997 Korea the regulators wanted to keep the economy moving along by having banks keep lending to already highly indebted industrial conglomerates (chaebol). They would presumable use the borrowed money to keep building new factories and employing more people.

In present day America the regulators want basically the same thing.

This is where credibly committing to bad regulation comes in. If a country has tough regulations on the books--like the US's Dodd-Frank--or it looks like they could be new laws, banks might begin to slow down their lending. This is what the regulations require them to do. But if regulators can credible demonstrate that they won't be able to gather enough information to enforce the regulations, then banks can feel safe lending at the same rate.

Sure, crony capitalism is a bad reason for weak regulation, but is a desire to keep the economy moving along also bad? I guess for tomorrow it's not that bad. So, why not have weak regulation all the time? Why do we need to go through this dance of credibly committing to weak regulation? Well, the expansion of credit (more and more loans) isn't always a good thing, especially when it is unlikely to be be paid back (this is part of why regulations were created in the first place). Regulations should prevent bubbles.

The problem gets worse if banks don't have enough savings to cover the bad debts. As we've recently seen, these problems tend to snowball, and it is typically the government (and the public's money) that end up covering the bad debts (for more nuance on government responses see this book by Guillermo Rosas).

Is it bad or good to weaken regulation by credibly committing to not have enough information to actually regulate? Over the long run, it seems pretty bad.

How can we get regulators, who may not even have their jobs over the long-run, especially if the economy stays bad, to break their credible commitments to bad regulation?

This gets to the second question.

Answer 2: In Korea the IMF came in and forced them to change. Hm, I don't know how practical this lesson is for the US. What are the odds that the US will have to implement IMF loan conditions any time soon?


Popular posts from this blog

A Link Between topicmodels LDA and LDAvis

Carson Sievert and Kenny Shirley have put together the really nice LDAvis R package. It provides a Shiny-based interactive interface for exploring the output from Latent Dirichlet Allocation topic models. If you've never used it, I highly recommend checking out their XKCD example (this paper also has some nice background). LDAvis doesn't fit topic models, it just visualises the output. As such it is agnostic about what package you use to fit your LDA topic model. They have a useful example of how to use output from the lda package. I wanted to use LDAvis with output from the topicmodels package. It works really nicely with texts preprocessed using the tm package. The trick is extracting the information LDAvis requires from the model and placing it into a specifically structured JSON formatted object. To make the conversion from topicmodels output to LDAvis JSON input easier, I created a linking function called topicmodels_json_ldavis . The full function is below. To

Set up R/Stan on Amazon EC2

A few months ago I posted the script that I use to set up my R/JAGS working environment on an Amazon EC2 instance. Since then I've largely transitioned to using R/ Stan to estimate my models. So, I've updated my setup script (see below). There are a few other changes: I don't install/use RStudio on Amazon EC2. Instead, I just use R from the terminal. Don't get me wrong, I love RStudio. But since what I'm doing on EC2 is just running simulations (I handle the results on my local machine), RStudio is overkill. I don't install git anymore. Instead I use source_url (from devtools) and source_data (from repmis) to source scripts from GitHub. Again all of the manipulation I'm doing to these scripts is on my local machine.

Slide: one function for lag/lead variables in data frames, including time-series cross-sectional data

I often want to quickly create a lag or lead variable in an R data frame. Sometimes I also want to create the lag or lead variable for different groups in a data frame, for example, if I want to lag GDP for each country in a data frame. I've found the various R methods for doing this hard to remember and usually need to look at old blog posts . Any time we find ourselves using the same series of codes over and over, it's probably time to put them into a function. So, I added a new command– slide –to the DataCombine R package (v0.1.5). Building on the shift function TszKin Julian posted on his blog , slide allows you to slide a variable up by any time unit to create a lead or down to create a lag. It returns the lag/lead variable to a new column in your data frame. It works with both data that has one observed unit and with time-series cross-sectional data. Note: your data needs to be in ascending time order with equally spaced time increments. For example 1995, 1996