On Fri, Jan 8, 2010 at 6:08 AM, Timothy Sipples <[email protected]> wrote:

> I should say right up front that I am not an expert on Korean banking.
> Also, I have no idea whether the following remarks apply to BC Card
> specifically.
>
> One commenter in this thread suggested that the number of transactions
> looks strange, if by "transactions" you mean "card swipes," basically. What
> I sometimes find -- and not just in Korea -- is that the term
> "transactions" has different meanings depending on whom you're talking to.
> The business users and managers tend to think of measurements like card
> swipes, purchases, etc. -- the direct business metrics. However, the IT
> staff tend to think of "number of CICS transactions" and/or "number of
> database updates," to pick two examples. Thus it's quite common for one
> card swipe to result in several "transactions," depending on the functional
> requirements and application architecture. Loyalty cards (point
> processing), fraud analysis and prevention, business reporting functions,
> overlimit SMS alerting triggers, PIN processing, interbank debiting and
> crediting, customer service functions, etc., etc. can also add considerably
> to the number of "transactions."
>
> So it's very important to decode that term whenever having detailed
> conversations about scale, sizing, growth, and other issues. If you don't
> have that common understanding of "transactions," it gets difficult to have
> meaningful conversations. In the context of a press article it's not a big
> issue at all, but when involved in IT design discussions it's quite
> important.
>
> Also, I recall that Korea has a lot more "real-time posting" of typical
> bank transactions than most other countries. If you think about U.S.
> banking, there's lots of batch processing for, say, check clearing. I think
> Korea handles their equivalent payments differently, much more like the
> real-time interbank settlements for larger transactions. At least, that's
> the explanation I constructed when someone once tried to educate me on the
> differences in better English than my Korean. Said another way, one Korean
> bank transaction does not equal one U.S. (or Chinese) bank transaction in
> terms of path length (for example). They are different creatures for some
> reason.
>
> South Korea, like many other countries, has had problems with high rates of
> credit card default in the not-too-distant past. That might be a reflection
> of what John is talking about (and which I have also heard), that Korean
> credit card companies have been very effective in saturating the market
> with cards.
>
> - - - - -
> Timothy Sipples
> IBM Consulting Enterprise Software Architect
> Based in Tokyo, Serving IBM Japan / Asia-Pacific
> E-Mail: [email protected]
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

I was talking about business transactions.  If the posting was talking about
internal system transactions required to affect the processing of a purchase
then several hundred million transactions per day is easily possible.
 However, the beginning of the article talks about a card holder base of 40
or so million people.  From that it seemed reasonable to think that the
transaction count was was directly related to the cardholders and not to the
internal system activity.  My comments should be viewed from this
perspective.

In the US the large card processors are running billions of internal system
transactions a day on distributed and sysplexed z/OS systems
to support hundreds of millions of card holder initiated transactions.

Regards,
Sam

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Reply via email to