26
Mar 13

Missouri Court Rules Against $440,000 Cyberheist Victim

facebooktwittergoogle_plusredditpinterestlinkedinmail

A Missouri court last week handed a legal defeat to a local escrow firm that sued its financial institution to recover $440,000 stolen in a 2009 cyberheist. The court ruled that the company assumed greater responsibility for the incident because it declined to use a basic security precaution recommended by the bank: requiring two employees to sign off on all transfers.

courthouseSpringfield, Mo. based Choice Escrow and Land Title LLC sued Tupelo, Miss. based BancorpSouth Inc., after hackers who had stolen the firm’s online banking ID and password used the information to make a single unauthorized wire transfer of $440,000 to a corporate bank account in Cyprus.

Choice Escrow alleged that BancorpSouth’s security procedures were not commercially reasonable. Choice pointed out that the bank’s most secure option for Internet-based authentication relied principally on so-called “dual controls,” or requiring business customers to have one user ID and password to approve a wire transfer and another user ID and password to release the same wire transfer.

Choice Escrow’s lawyers argued that because BancorpSouth allowed wire or funds transfers using two options which were both password-based, its commercial online banking security procedures fell short of 2005 guidance from the Federal Financial Institutions Examination Council (FFIEC), which warned that single-factor authentication as the only control mechanism is inadequate for high-risk transactions involving the movement of funds to other parties.

But in a decision handed down on March 18, 2013, a judge with the U.S. District Court for the Western District of Missouri focused on the fact that Choice Escrow was offered and explicitly declined in writing the use of dual controls, thereby allowing the thieves to move money directly out their account using nothing more than a stolen username and password.  The court noted that Choice also declined to set a limit on the amount or number of wire transfers allowed each day (another precaution urged by the bank), and that the transfer amount initiated by the thieves was not unusual for Choice, a company that routinely moved large sums of money.

Like most U.S. states, both Missouri and Mississippi have adopted the Uniform Commercial Code (UCC), which holds that a payment order received by the [bank] is “effective as the order of the customer, whether or not authorized, if the security procedure is a commercially reasonable method of providing security against unauthorized payment orders, and the bank proves that it accepted the payment order in good faith and in compliance with the security procedure and any written agreement or instruction of the customer restricting acceptance of payment orders issued in the name of the customer.”

The Choice Escrow judgment may be among the first to focus on a particular aspect of the UCC (Article 4a), which states that if the bank offers to the customer a security procedure which the customer declines, the bank can argue that its procedures were commercially reasonable, said Dan Mitchell, an attorney in Portland, Me.

“Really, it looks like that’s what this whole case was about for the court, which didn’t examine whether the bank’s security procedures were commercially reasonable,” said Mitchell, who recently represented Patco, a Maine construction firm that successfully sued its bank for poor security following a $588,000 cyberheist that also took place in 2009. “The court’s whole analysis was about the fact that the bank offered dual controls which the customer declined.”

Charisse Castagnoli, a bank fraud expert and independent security consultant, said the fraud incident happened before banking regulators issued the current online banking security guidelines, which call on banks to take additional steps to protect customers from account takeovers — including educating customers about the sophistication of today’s threats.

“The bank’s security may not have been sufficient by today’s standards, but the key here was that the bank offered a security measure that was refused,” Castagnoli said. “If the bank doesn’t ever make the recommendation to use additional controls, then shame on them. But in this case, it seems like the bank was trying to steer their customer to use those controls. Considering this was back in 2009, it looks like the bank was at least doing a pretty good job informing their customers about the need for dual controls.”

Choice Escrow declined to comment, or say whether it planned to appeal. But according to Castagnoli, summary judgments can be difficult to appeal. “It’s pretty expensive, and the standard of review for the court is fairly high.”

There is no doubt that requiring two employees to sign off on all transactions minimizes the potential for fraud (particularly employee/insider fraud). But dual controls alone are hardly sufficient. The very first cyberheist case that I wrote about — back in the summer of 2009 — dealt with the electronic theft of $415,000 from Bullitt County, Kentucky. Bullitt had set things up so that all payments had to be initiated by the county treasurer and approved by the county judge.

In that attack, the crooks had compromised the treasurer’s computer, which allowed them to change the email addresses that were to receive notifications about new transactions. They were able to do this because the treasurer was the designated administrator of the county’s account settings at the bank. They then changed the judge’s password in the bank’s system, and approved the fraudulent transfers using a computer outside of the state of Kentucky.

The best way to avoid a cyberheist is to not have your computer systems infected in the first place. The trouble is, it’s becoming increasingly difficult to tell when a system is or is not infected. That’s why I advocate the use of a Live CD approach for online banking: That way, even if the underlying hard drive is infected with a remote-access, password stealing Trojan like ZeuS or Citadel, your online banking session is protected. This is just one of the tips from a much longer list of precautions that small- to mid-sized businesses should consider adopting when banking online.

A copy of the court’s decision is available here (PDF).

Tags: , , , , , , , , , , , ,

41 comments

  1. I wonder how the courts would have reacted if this happened after the release of the 2011 FFIEC guidance supplement.

  2. This is an interesting court case to say the least. The question may not necessarily be that the Bank did not have adequate security policies in place but if Choice Escrow would have actually used it in the first place.

    Since they declined the existing security features that the bank had (dual controls and setting a limit on the money to be transferred) what reasonable case is there that Choice Escrow would have chosen any other additional security features?

    Its seems to me that Choice Escrow messed up big time and decided to blame someone else. But on the other hand using second factor authentication like a hardware token would have stopped the transaction in its tracks.

    Now if we only knew what else the (potential) malware on one (or more?) of Choice Escrow systems is doing?

    • As I understand it, even hardware token security can be compromised, because the token value is time-limited instead of use-limited. If the token value is good for a limited time (before another token value is generated) then it can be captured and immediately used by someone other than the authorized user.

      • Most token systems will only accept a given token for one valid authentication. If a second transaction occurs within the token value’s lifetime, the user must wait for a new token code before authenticating the second transaction.

        • You’re right about most two-factor tokens only accepting one use of the token password, but Man-In-The_Browser attacks have been used very successfully against two-factor authentication.

          Out-Of-Band two-factor authentication (e.g. with a cell phone text) ups the ante but can still fall to a MITB attack. A LiveCD or dedicated system is the way to go if you really want to be sure.

      • Tokens are, at best, a speed bump, particularly if the bank does not ask for a token at the transaction time. If a financial institution only uses tokens at login, these are easily overcome by the attackers. The bad guys in most cases already control the victim’s browser. They can use Web injects to manipulate the way the bank’s site is displayed in the victim’s browser, so that when a token is requested and submitted by the authorized user, that token is redirected to the attacker, and the victim sees a “please wait” screen or is redirected to a fake “site is under maintenance” page. In either case, the bad guys can and routinely do use that window of time to interactively log in as that user.

        That’s why dual token requests are key: If the victim didn’t move to make a transfer, they’re not going to enter that key the second time (ideally). This is not a foolproof method, but it is a darn sight better than just asking for a token at login.

        • What about having the browser display a code for verification, and then have the bank call a phone number on file for that customer and asking them to dial in the code? This would mean the attacker would have to have hijacked the actual phone number to complete the transaction.

  3. Krebs on Security has recommended in a number of articles that people use Live CDs as a way to avoid letting infected harddrives steal banking information. Currenlty, I use a virtual machine on my main box to do all my banking. When I mention this to security professionals, there’s always a moment of hesitation – No one seems to have an example of a VM getting compromised, but everyone thinks it’s possible.

    Does anyone have any insight into how safe browsing/banking is with VMs?

    T.

    • The problem with using a VM is that if either your main system (hosting the VM) or the VM itself gets compromised (say, someone gets a key logger on there) then it is — effectively — game over.

      I would therefore consider the VM approach to be only slightly more effective than the dual-browser approach (one for banking the other for regular work). Certainly not as good as a live CD and nowhere near as good as a dedicated system.

      (An issue with the live CD approach is that every time you boot you are loading up software which is inherently several months out of date with respect to security patches. Now, given that Linux is — currently — not that much of a target and that the CD is only meat to go to online banking sites and back you’re probably fine but it is something to note. Hence, why I would advocate having a Linux install on an external hard disk which is updated regularly with the disk only connected when it is to be used.)

      • What Freddie said.

        The fact that no has so far compromised a VM is just like the guy, the day before zero-days were invented, saying that his approach of using a 100% signature-based anti-virus solution is without flaw.

        That said, I think Brian’s recommendation to use Puppy Linux will work for virtually everyone. Banks do not update their software very often, so I think everyone will be fine using Puppy Linux and burning a new CDROM with each new release.

        • Correct. The VM is only as secure as the host OS, and if the host OS is compromised, all bets are off. That’s why I’ve been a bit of a broken record on the live CD approach. It’s not foolproof, because as previously stated people tend not to burn a new live CD when a new distribution of that live CD’s OS is released. But then again, I’m not aware of any cyberheists involving attacks that targeted recently-patch Linux vulnerabilities.

          • I would agree that at the moment almost all non-business users are safe. But these corporate heists are often on the order of $100,000 USD or more and almost certainly in the targeted/spear-fishing regime.

            If I were in the game (and I most certainly am not!) my strategy would probably be along the lines of:

            1. Use a spear-fishing type technique to infect the host OS of the user in question. There are more than enough exploit kits which fulfil this role and can compromise many Windows systems which are not kept up to date.

            2. Download a payload to assault the NAT router of the user. These appliances often have little-to-no hardening, are seldom updated, have web interfaces which are vulnerable to XSS (especially dangerous considering that it is often possible to enable shell access through this interface) and use libraries which have known buffer-overflow vulnerabilities (see anything to do with UPnP). Once the router is rooted it can be instructed to proxy relevant traffic to the attacker. “All your bits are belong to us.”

            3. Wait for the user to use their live CD. Thanks to browser headers and the power of JS it should not be too difficult for the attacker to fingerprint the CD and download the exact release in question. At this point the attacker has an exact replica of your OS in a VM. All s/he then needs to do is look at the security updates which are available and browser-facing and try to find one that works. (The nature of open source makes this a relatively simple process.) Here the attacker can take as much time (within reason) as they need — after all these CDs are probably only burned once/twice a year.

            With a vulnerability in play (probably using exploiting some horrific bug in graphics stack via WebGL) all that is left to do is somehow redirect the user to a website other than their banks. So long as they do not type in the full URL (incl. https) each time this is eminently possible. At this point it is game over.

            Is it a lot of work? Yes. Is it far-fetched? Possibly. Is $100,000 a strong enough of a motivator? You bet it is.

            • “Download a payload to assault the NAT router of the user.”

              I admit I am in over my head, but if that router was given a complex UID/password and had UPnP disabled, would your idea still work?

              • Perhaps. These devices have absolutely massive attack surfaces: DHCP, DNS, UPnP, HTTP, …, all it takes is for there to be a buffer overflow in one of these network-facing surfaces for the game to be over.

                Given how infrequently these devices are updated and the fact that they have almost no hardening (no ASLR, DEP, or MAC — which all serve to mitigate the impact of buffer overflows) they are comparatively soft targets.

                I would not be surprised if we see “NAT router exploit kits” on the market in 18-24 months. Once you’ve got a system inside of a network why not take over the gateway and have a persistent entry point into the entire network. Fun for the whole family! That, and who is going to suspect their innocent little router at being the source of their woes? (As an example of a potential use-case for a rooted NAT router look at Brian’s excellent description of the iTunes auto-update flaw used by FinSpy. Finally, let us not forget that a NAT router also makes a great botnet node for conducting denial of service attacks.)

                To say I am scared about this is an understatement. The worst, in my opinion, is yet to come.

            • I’m assuming that’s why one of the banking victims that Brian featured stated in a recent comment that his company is now using both a dedicated computer and a completely separate (dedicated) DSL connection for its online banking.

            • If the router is hackable directly, why bother with methods one and three? Just redirect the traffic through the hacker’s system and manipulate the bank transactions via MITM.

              Method one is only useful if the router can’t be hacked directly from the Internet which might be true but not necessarily.

              Who needs a replica of the Live CD OS or even care about the Live CD? If the bits going over the wire are under the hacker’s control, everything is.

              A dedicated computer and dedicated DSL line are no help, either. The dedicated computer has to be hooked up to do the transaction and it can be compromised in the time it takes to do that transaction if it’s not fully patched and hardened. And if it’s only used for bank transactions, it WON’T be fully patched since it has not been online to be patched automatically.

              A dedicated DSL line would help a bit since a DSL modem probably has less attack surface than a full consumer router. But MITM is still feasible.

              A-a-n-n-d-d we’re back to my meme! :-)

              Seriously, though, a Live CD (or USB which would allow for updating) approach is better than anything else being done today. There is no security, but you can still make the attacker work a little harder to make that true.

              • Of course, MITM is no good if the entire connection is encrypted end to end, and by that I mean not just browser SSL, but some sort of VPN.

                If a company uses a VPN service to access their bank, like people do to access geographically restricted media content, that would help. The only risk is on the bank side of the connection. If the VPN is set up from the OS, then router compromise becomes irrelevant except to the degree that certificate compromise is feasible.

                However, choosing a safe VPN provider then becomes an issue, which presumably has a “reputation” solution.

                And if the bank supported a standard VPN protocol connection, that would be even better. But that probably would raise the bank’s costs, as a full VPN connection takes up more server resources than a browser SSL connection.

              • While there’s no doubt that your meme will always be valid, at some point the saying “Don’t Let the Perfect Be the Enemy of the Good” deserves its due.

                If everyone attempted to avoid every infinitesimal risk, as is regularly demonstrated in discussions on this specific topic, the world economy would most likely come to a screeching halt.

                • The problem is that the conventional notion of “security” leads directly to trying to avoid every infinitesimal risk – something which is doomed to failure.

                  My notion is that you accept there is no security and do more along the lines of handling a threat rather than trying to prevent or avoid it.

                  Also, the notion that security negatively impacts performance and corporate goals results in security being minimized. A better notion is that security IS one of the corporation’s goals and needs to be better balanced with the other goals.

                  It does one no good to make a ton of money if someone then steals it from you. Which is precisely the problem these small businesses are having.

                  Fortunately the notion that security HAS to interfere with productivity is mostly false. What matters is how well security functions are designed and integrated to corporate functions.

              • Actually, a dedicated DSL connection to the bank can do a lot of good as long as the dedicated system is never connected to the Internet, only to the dedicated connection. It means the dedicated computer becomes pretty much a dumb terminal that sits on the bank’s edge network (in much the same way as an ATM does) and the only possible ingress from the Internet would have to be through the bank itself, a much more strongly defended network than a small business’s LAN. This means that the source of the media used to load and update the dedicated system must be impeccable, but it’s a lot harder to infiltrate a system whose only connection to the outside world is through the bank itself.

                • True, but I doubt many banks want a permanent connection to their network from every business they work with. For one thing, that becomes a security risk to them.

                  A VPN on the other hand sets up and tears down only when used.

      • I’m not certain an external hard drive OS is a better choice for banking than a Live CD. With a Live CD there’s no chance that malware could be installed into the OS (at least not over multiple sessions), and therefore each boot would be fresh. As far as unpatched distros go, anyone taking the time to do this sort of thing should really be on the distros mailing list and making a new Live CD every time they get a patch. Personally I use Tails and I have to make a new disc every few weeks but honestly that’s the price of overzealous online banking security.

        As far as a hacked router, well, that’s a topic for a whole other discussion.

        I think all security experts and readers of this blog are aware that there is no 100% secure method of handling money, not even physically at the bank with a relative as the teller (bank robbers with guns?). The point is that everyone has to decide their comfortability level with each new stage of security. In the CEH course it was really pounded into my head that a “security at all costs” approach to IT doesn’t benefit anyone because you then lose functionality and ease of use, both of which are critical to business infrastructure. As much as we’d all like to have a dedicated computer, guarded 24/7 by ex-Spec-Ops Commandos with a (also heavily guarded) dedicated ethernet connection wired directly to the bank, where a dedicated bank attendant (thoroughly vetted by the FBI) monitors and personally processes all bank transfers through similarly secured means, (deep breath) who has the kind of discretionary fund for all that?

        I think anyone here using any of the methods listed above is safer from bank fraud than 99.9 percent of online banking customers, and for that, I’d like to say thank you to Brian and the many IT Security professionals out there bringing awareness to these problems.

    • With VMs I’d assume if you hit Print Screen you’ll get a screenshot with the VM window open, right? So I’d say VMs are good to browse a possibly infected site or something because no damage will be done to your actual OS, however it doesn’t work the other way around. If your OS is infected then it can probably see what you’re doing with the VM.

      LiveCDs could possibly be infected if a unearthly BIOS virus built for your specific Linux live cd was infecting your mainboard, but if that’s the case then you have bigger problems to worry about, cause that’d be extremely rare.

      For 100% secure internet banking, don’t even use it. Drive down to your bank and stand in line.

      • For 100% secure internet banking, don’t even use it. Drive down to your bank and stand in line.

        Then, only interact with a teller you know. Well. Having gone to school with them is good. Being related is better. Being related by blood is best.

  4. This legal finding is actually a good thing. We as a country aren’t doing enough to impede cyber-crime. The way it is now, the banking institution is taking the hit 95% of the time, which to them is a cost of business and is passed right back onto all of us. In this way, the little guy is hurt and and the problem is hidden from the masses. If we start making companies responsible for insuring their banking methods are safe we start sharing in the overall need for awareness. The problems are too varied and insidious to trust that the banking sector alone will handle it. The company, whose money is actually at stake, needs to know how to help prevent passwords from being stolen, and why its necessary. We can’t have 250 million clueless dolts and a few responsible entities that try to save everyone else from indifference.

    • We were compromised. It is not as simple as your comment makes it appear. We had an ‘incident’ resulting in an unauthorized transfer from our account. These attacks rely on technical sophistication as well as some level of social engineering.

      If I did ever thing in the company, we would most likely not have been hit. Each company will have users at varying technical levels The fact that I regularly read blogs like this means I am several orders of magnitude more technically savvy than the typical user.

      We regularly receive many email attachments daily. An employee clicked on an attachment which started the process. The attachment appeared to originate internally and appeared to be something the employee might ordinarily receive.

      If it had been addressed to me I would have not have opened it because if I am not sure it never gets opened. There were enough clues for a technically savvy user. However most employees will not and cannot be expected to have the same level of knowledge as someone working with computers as a programmer and administrator for multiple decades.

      The computer was running the latest updates and antivirus; all up to date as well as a firewall. The initial payload disabled them and then did the dirty work with a man in the browser attack.

      The bank’s system was simply vulnerable; it is not my call on which bank we use. I had prior email correspondence to the bank requesting additional options and were told they were not available. In other words we used what they had. By the way once inside the network the attackers were able to then compromise multiple computers of other key users.

      Running the latest updates, antivirus and firewalls is not enough. The banks’ security has to be the first line of defense. If the bank’s system is ‘tougher’ and your internal procedures are ‘tougher’ most likely the easier guys will be the ones hit. However don’t fool yourself, most systems in use today are very vulnerable to attacks that rely on a combination of technical sophistication and social engineering.

      • Hello bnon,

        What you’re saying seems to contradict Brian’s story. His article says that court’s decision “focused on the fact that Choice Escrow was offered and explicitly declined in writing the use of dual controls…”

        But you’re saying that you contacted the bank, and they had no additional options to offer you.

        I obviously don’t know all of the details, but something isn’t adding up.

  5. > unauthorized wire transfer of $440,000 to a corporate bank account in Cyprus.

    It sounds like the account of that illegal wire transfer is about to take a haircut by the time the banks reopen in Cyprus…

    • When I read $440,000 to a corporate bank account in Cyprus, my first thought was “That is someone’s escrow money. The deal to purchase their new home just hit a snag”.

  6. NotEvenCloseEnough

    Live CD is hacked .

    • Richard Birenheide

      Care to elaborate?

    • While I haven’t heard about Live CD Hacking, I’m certain the bad guys are looking at how to insert themselves into Live CD just to have access to the banking credentials again. This is by submitting patches with an obscure back door, etc.

      • All of them?

        There are dozens of live CD options to choose from – and while they might not be updated frequently, they have the reverse benefit of nothing being able to dump onto the disk either. Short of the bank site itself being infected you will probably be okay.

        • Yeah, no kidding.

          Puppy Linux, now in version 5.5 for Precise, comes up quickly, but it uses a non-standard browser, Seamonkey. It works with my bank which surprised me a little at first.

          Fedora 18 LXDE also works as a Live CD, but I must admit I only run it with the disk disconnected. I have no idea what happens if a drive is still attached (but if disconnecting a drive makes you uncomfortable, you are in the wrong blog). It does not come up as fast as Puppy, but it has the added advantage of using Firefox. For that reason, I like it better than Puppy.

        • >There are dozens of live CD options to choose from

          99% of the people will not evaluate the dozens of live CDs; they’ll just use the first suggested live CD. For the type of money at stake, the bad guys can afford to hire programmers for years to create and submit quality patches and upgrades that get included into the live CD. Or they can target the browsers in the same way: Firefox and Seamonkey. A good programmer can insert stealth code that triggers only when going to a banking site. No need for interim storage.

          Who is reviewing those hundreds of millions of lines of open source code? Sure, the gatekeepers review the patches, but after they’ve worked with trusted submitters for a time, there is no longer a need to review every line of every patch.

          • While I agree with you in theory, I think it is far less likely than you asserted.

            I have worked in a few places where, not only did the manager or another developer review my code after it was checked into the source library, they removed my comments! This says a lot about their personality, but that’s another story.

            To minimize the possibility of “Manchurian developers,” one should use one of two distributions:
            1) The smallest one, to minimize the number of people who are involved. The smaller the team, the lower the odds that low-lifes will be able to burrow their way in. We have come full-circle, because the best example of this is Puppy Linux, Brian’s choice. Chinese or Russian teams should be avoided, however.
            2) A small distribution from a larger company, with Fedora LDXE being a prime example. This minimizes the number of developers, while still having lots of eyes on the original source from which it is derived.

            I think I would avoid anything from Canonical because of its new relationship with the Chinese government.

            Perhaps one should not migrate to a newer release to prevent future additions from “Manchurian developers.” Of course, then one must decide when to stop.

  7. Until global law enforcement agencies start going after the people behind these types of fraud, this problem will continue on. It’s either you better secure the internet as a whole or just accept the fact that people will not take internet security serious enough and will fall victim to the internet criminal element

  8. Authenticating a user at login, regardless of whether single-factor or multi-factor, is merely a speedbump. It keeps the honest folks out similar to locking the door on your house.

    Authenticating the actual transaction on the customer’s end, with a token for example, is a step in the right direction, but it doesn’t solve all the problems with today’s sophisticated attacks. Even some out of band authentication methods can and have been overcome with blended attacks that include VoIP compromizes.

    Customer call-back procedures should be pretty standard in financial institution policies. As far as cybersecurity insurance coverage policies that are sold to banks go if there is not an out of band customer call-back procedure on wire transfers it is highly unlikely that the financial institution will ever collect a dime. Also of note, cyber security insurance policies that are intended to cover bank losses from this sort of fraud usually have so many stipulations and exclusions that it is nearly impossible to collect a claim, much less warrent paying the policy premium.

    Dual authentication/control is pretty solid control, and is used extensively in most financial insitutions for internal systems and policies, but it isn’t necesarily going to solve problems where a business PC used to perform online banking is compromised.

    Daily and weekly transaction limits are a great control and can be used to limit the risk exposure of both the customer and the bank. The financial institution needs to be looking at the overall customer risk profile from both a credit risk standpoint, and also from a customer history standpoint and setting hard limits on external transactions. Overriding these limits should require written approval from an officer of the bank, and better yet senior management at the business.

    Ultimately the financial institution needs to be authenticating the transaction. This should be fairly easy for a small financial institution that has less than about 30 commercial internet banking customers because that size of institution is able to personally meet, know, and assess each individual business…they know those customers by name, they know their voice, and generally they know what sort of volume their customer is going to send and when they are going to do it before that business even logs in. Once you get past that size the economics of scale start to dictate that the bank’s electronic funds transfer group isn’t going to be able to personally know every single customer and at that point financial institutions need to start relying on other means to authenticate transactions, generally falling into the realm of automated technical controls that look for patterns and anomolies. The higher quality anomoly detection systems work quite well…Visa and Mastercard have been doing this for years…but they are extemely expensive (think 5 digits plus).

    Customer training is important and does help from what I’ve experienced, but most SMB customers using online banking simply do not ‘get’ security or have the resources to expend on having strong security.

    Also note that the transactional risk for an ACH transaction is generally lower than a wire transfer for both the bank and the customer. The clearinghouse rules for ACH and Wires are quite different. Throw in international transfers and the gap widens even further. An ACH transaction can generally be recovered if it is caught soon enough. Once a wire leaves the originating bank it’s generally a done deal, especially if that wire is international. One thing I really don’t get about financial instutions allowing these overseas wires to go out is that with any wire transfer (and international ACH) there are Bank Security Act procedures required such as performing an OFAC check. Unless the financial instituion is so large that they are automating (and not reviewing these) you would certainly think that an international wire transfer to the former Soviet Union would set up some pretty strong red flags.

    Live CDs are all fine and dandy if you can actually get customers to use them.

    And of course the best way to prevent this type of issue is to layer most (if not all) of these controls together and at the end of the day remember that you can never eliminate risk, you can only mitigate it.