Credit Card Travel notification question

Factual Questions
41

Yes, there are all kinds of problems, the whole process does not deal in absolutes. Activity that looks amazingly shady can be completely legitimate. It can look perfectly legitimate and be completely fraudulent. There is attempting to balance bad experience for the customer vs. fraud losses. Something that won’t raise a flag in Estonia may raise one in Latvia.

In my role I am an advocate for the customer experience. I’ve butted heads many times with people in the risk departments trying to find the best balancing point. And they’re not unaware of bad or confusing experiences but just as I’m yelled at by executives wondering why 4 people (out of millions of customers) complained about X this week, they get yelled at to explain why we were so stupid as to allow $X of fraudulent charges in Kenya this week.

I’ve yet to be in a room where everybody made sure all the doors were closed and then whispered to each other “now how can we make this the most fucked up experience possible to trick them out of their money?” Maybe those meetings happen when I’m not there.

And remember, if you’re legitimately trying to use your credit card in Bosnia to buy perfectly legal white powders in is in our interest to let you do that. That’s how we make money. Ideally we’ll never reject a legitimate use of the card.

42

Thanks every one, but those are all good answers to a question I didn’t ask.

**I just wonder why I have to wait until 5 days before I’m traveling to tell them.**I would like to tell them now and get it out of the way.

Shitty DB design is all I can come up with. I would just like to tell them that I will be in Germany from/to such and such dates.

Perhaps I should have just pitted my CC company for this stupid rule.

43

Capital One lets you set travel notifications from their web site up to 120 days in advance. So there is no inherent reason why it needs to be just 5 days. It’s just the policy of your issuer.

44

It’s a combination of shitty DB and system architecture design (or more likely, sensible DB and system architecture design that has moved ungracefully into a future it never envisioned) and risk modeling policy decisions.

For example, when I was working on one travel notification system (this would have involved debit cards, not credit cards). One of the systems involved, external to my company but one that absolutely had to be used had no ability to store future dates. Foreign travel notification is either simply on or off. I do not know why, but none of the people who work there are idiots so I assume there were good reasons for it at the time.

So the choice was to either:

  1. Find another vendor and spend millions of dollars switching to them.
  2. Try to insist that the vendor upgrade in this way and probably end up paying for that (and hope they do it right and on a schedule that is useful to us).
  3. Build an infrastructure on our side to store this information. Which sounds easy (and is, relatively speaking) but also would cost a lot more than you’d expect. For various stupid (though sensible intially) reasons there are actually a half dozen systems that can take travel notifications, each of which will need to be update and then it just becomes a permanent part of the ecosystem which has to be maintained, tested, etc., and is prone to breaking if that vendor ever changes their system in an unexpected way.
  4. Find the best customer tradeoff for working within the existing system. Which is even more attractive when the other options are compared against an issue with a very difficult business case (1% of customers will ever even submit a travel notification and only 5% of those will try to do so more than X days before travel and the risk monitoring will only reject Y% of transactions without a notification).

And so, “shitty DB design” results in a confusing policy decision to allow people to submit a travel notification only a week in advance since in reality that will immediately be transmitted to that vendor which will immediately apply it even though the customer said they won’t actually be traveling for another five days.

The customer experience isn’t as crappy as it could be (we didn’t require they wait until they’d landed at their destination), but not remotely close to ideal. And we were able to implement the ability to do even do it for a cost that allowed it to be done. And from the customer experience point of view it just ends up looking like thoughtless stupidity.

live with that or build a separate structure internally just for storing that information and then transmitting it at the appropriate time. Which isn’t a horribly complex proposal but also isn’t as cheap as most would expect. So a very short lead time limit was imposed because what would actually happen is the customer would say “I’ll be traveling internationally beginning on Monday” and it would get transmitted immediately to that system as “This person is now traveling internationally.”

That 3-day window was viewed as risk acceptable between having the fraud monitoring turned off excessively (and thus increasing our exposure) versus the customer experience hit. Another consideration is that while a small population will take the effort to inform us that they’ll be traveling, almost nobody will take the effort to inform us when those plans are canceled and keeping the window relatively short is a policy decision to minimize issues around that.

Like I said above, customer may not agree with the decisions, and there is a lot of stupidity (though often it wasn’t stupid when it was first created) on how core banking systems are architected because many of them are pretty old, and their hard to change in fundamental ways due to backwards compatibility requirements and there’s a certain reticence to risk even a transient failure of the risk monitoring system to give the 0.002% of the customer base that would use it the ability to submit travel notifications at an indefinite distance in the future. Sure that risk is very small, but so is the benefit (to anybody), and if realized the damage is potentially very large.

Then add to that a roadmap that makes it look like travel notifications won’t be needed at all in just a few years to that effort would be redundant.

45

Yeah, I had no problems with my Cap one card.

obfusciatrist - I’m a programmer myself, and I know some things are not as cheap or simple as one would expect. But really, implementing a separate system to hold the dates of travel and throw legacy systems ‘travel’ switch on the card on a certain date sounds absolutely trivial.

46

Do you travel overseas frequently? It might just be a case of “usual patterns”. If the other couple rarely leave the country and then suddenly start charging their card in lots of exotic places, it will raise a flag.

I used to advise my bank of overseas trips but I never bother now. Six-month round the world trips, month-long Inter-Rail journeys around Europe through a dozen or more countries? No problem. And yet just the other day I had a call from the fraud department after I tried to pay £150 to a mobile phone network to upgrade my phone!

As to the OP’s question: crappy bank computer systems. Lots of banks seem to be running on incredibly outdated systems. Even in the UK, which tends to have a slightly less byzantine banking system than the US, we’ve only recently had the facility to make instant payments to another account without waiting three days for that online payment to be “cleared”.

47

You’d be wrong. At least where I work. The actual task is extremely simple. Integrating that take into everything that would need to use it isn’t. If the whole thing were being architected from the ground up it would be a small thing. But if we estimated a project based on just that requirement (“Allow travel notifications to be submitted at any period beforehand and not go into effect until the start date”) I’d guess it would come back in the 15,000-20,000 hour range. And that is just for the systems I’m aware of.

Should it be that way? No. And there is a constant struggle to make it not be that way. And I’m sure other banks are at very different places on a spectrum of how expensive it would be to do this.

And then compare whatever it would cost, even if it were cheap, against policy reasons for deciding that an indefinite lead time is not desirable either and the fact that systems are moving in relatively short order in the direction of notifications being completely unnecessary.

Again, I’m not remotely saying there are GOOD (especially when viewed from a pure customer experience point of view) reasons for it. But generally it isn’t just thoughtlessness but intentionally considered tradeoffs that result in the weird user experiences. But at your institution it may just be thoughtless stupidity. It may be because their legal department has interpreted some regulation as allowing no more than 5 days notice (that happens a lot too, lawyers at different banks reach different conclusions of what some law requires; many times I’ve been told “Reg X says we can’t do that” and I reply “Then how come our main competitor can do it?” And they say “We think their lawyers are wrong.”). It may be because travel notifications weren’t particularly important and some small department peon had enough budget to fund a project that didn’t get exposed to normal design scrutiny and just kind of fell through the cracks.

So, lots of words to agree that the short answer to your question is:

There is no statutory or regulatory reason that requires your bank only accept travel notifications 3 days or fewer from the start of travel. So regardless of why it evolved that way, there is likely no reason for it that won’t seem stupid from a pure customer experience point of view.

48

When I was at a bank that no longer exists it was painfully expensive to update the system to end this:

[ul]
[li]Customer A has a checking account that they opened in “Region A”[/li][li]Customer A also has a checking account that they opened in “Region B”[/li][li]When they logged into online banking they could see both checking accounts.[/li][li]But because of legacy issues in the backend (Region A and Region B used to be separate banks that later merged) we couldn’t just transfer money between the two accounts.[/li][li]Any transfer got sent as an ACH transfer which A) Created delay and B) Cost us money.[/li][/ul]

It took years and tons of money to get this fixed (as a technical issue it was an easy fix), for reasons that were completely reasonable to many people inside the bank (some of whom are in a position where zero risk is better than improving experience) and completely stupid to customers.