Tag Archives: GXS

Goliath is Lashing Out At David


Goliath knows his days are numbered. He is a couple of generations away from David. He looks tough, but he is not. But he keeps trying:

From: Robert Heidish | GXS [mailto:GXS.INTERCONNECT@GXS.COM]
Sent: Thursday, August 08, 2013 3:46 PM
To: EDI Systems
Subject: Service Announcement: New Loren Data Setups will be suspended November 1, 2013

9711 Washingtonian Blvd.
Gaithersburg, MD 20878

800-503-9190 t
301-340-4000 t
301-340-5299 f http://www.gxs.com

August 8, 2013

Service Announcement: New Loren Data Setups will be suspended November 1, 2013

GXS will no longer process new trading partner requests on the Loren Data network VAN Interconnect starting on November 1, 2013. This moratorium on new connections is being implemented to ensure that all clients impacted by the upcoming termination of the Loren Data VAN Interconnect are provided enough time and notice to migrate to alternatives.

Any GXS client enabled and defined to the Loren Data VAN Interconnect prior to November 1, 2013 will be able to use the service up until the date of termination which is March 4, 2014. GXS will be monitoring the environment from November 1, 2013 through March 4, 2014 to ensure that all users have been notified and migrated.

GXS maintains over 100 VAN Interconnects – more than any other service provider in the market. We would be happy to work with you and your trading partners to find a solution that supports one of our alternative VAN Interconnects or a solution natively on GXS.

If you have not already contacted us in regard to this matter, we have a support team ready to assist you in exploring alternative options to route your data if needed. Feel free to contact this support team by sending an email to GXS.INTERCONNECT@GXS.COM. More information can be found in the Interconnect Service Announcements section of our GXS Support Services website.


Robert Heidish
GXS Messaging Services Product Manager


Can’t understand why anybody in a go-go industry would want anything to do with a company stuck with 1990’s technology. Maybe GOLIATH is really a DINOSAUR in drag as a human?


EDI VANs Are Undefined At Best


VAN (Value Added Network) has history but no formal defining document. It isn’t part of the X12 and isn’t anywhere required. There is a lack of an existing generally accepted definition of what a VAN is. We will tie this in with the notion that they exist for the purpose of promoting and enabling transfer of data between trading partners, but that they are not a requirement of the process or infrastructure.
Earlier this year, I wrote on “What Is EDI? – A Definition and History“. I concentrated more on the standardization of DOCUMENTS, not how to exchange them. I covered how the Transportation Data Coordinating Committee (TDCC) morphed into the American National Standards Institute (ANSI) and became the ANSI X12 Committee and how on the other side of the ocean, standards for documents used in international trade, called Tradacoms , were developed. These bodies adequately took care of controls for individual documents and multiple documents (mailbags, etc.), but nary a word about actual delivery to the trading partner. It was left up to the user, but the vendors jumped into the drivers seat.

Loren Data, GXS and Daisychaining


In the early 1970s MCI filed an antitrust suit against AT&T alleging that AT&T held a monopoly position in the telecommunications industry. A part of its claim was that MCI was unable to compete fairly against AT&T because of pricing and access control AT&T held. Consumers at that time had few choices in long distance carriers because AT&T restricted the ways that MCI was able to offer its services. All that changed in 1980 when MCI won $1.8 billion in damages from AT&T and the Department of Justice led the breakup of the Bell System. But what does that have to do with today’s supply chain?
In December 2010 Loren Data Corp filed an antitrust suit against GXS, Inc. alleging that GXS used its market position by denying Loren Data Corp competitive access to its network, while granting similar access to other competitors.

David versus Goliath Continues


As you may know, Todd Gould was notified on June 4, 2013 that GXS has begun notifying its customers of its intention to terminate connectivity to Loren Data’s ECGrid® EDI Network on March 4, 2014. Ever since then Todd has received a lot of support from individuals in EDI forums.

We are going to try and give you some of those comments (abbreviated). Going to keep the same picture, not only because it’s cool; but because we bought it. (Todd, you can buy us a cup of coffee the next time you are in Nice.)

June 5, 2013

Todd Gould replies to the faithful

I am overwhelmed by the letters of encouragement I have already received; however, I am also bitterly disappointed.
Everyone who has any concern over these actions by GXS needs to speak out publicly, now. If you cannot go on the record representing your company, then speak out for yourself. If you can’t do that, then make some noise at your company so they understand what is going on, so they can speak out. Remaining silent only supports GXS, tacitly, but support nonetheless.
If you are with a VAN and you currently have EDI Service Providers as customers, be ready for a letter from GXS in the very near future banning all EDI Service Provider traffic from transiting your TGMS and Inovis interconnects. GXS is going to make your customers pay and connect to GXS directly for all that traffic. Think about it.
If you work for an EDI Service Provider shouldn’t you be able to choose whichever VAN you wish to route your customers’ traffic? Very soon your VAN (if it is not GXS) will be told that your customers’ traffic can no longer go over the TGMS interconnect, you will need to pay for another account on GXS. And if you would rather have interconnects to each VAN, shouldn’t you be able to do that on the same terms as any other VAN? Why made GXS king of deciding who can play and who has to pay?

If you are an end user, make no mistake, GXS is willing to interfere with over 10,000 trading partnerships and all the commerce that represents in order to control the market. These are your relationships, representing your supply chain, your business. Do not let GXS use your business to harm competition in this market.
If you are a GXS customer affected by this, call your account rep and ask them why they are doing this. How is this serving me? Tell them you want your trading partners to use whatever systems they want, and if that requires interconnects to ECGrid or any other service provider, then GXS should put them in place.
Not since AT&T v. MCI have we seen anything like this. It was bad for the market then, it is bad for the market now.
If you don’t speak out, you are supporting GXS’s actions.
Now is the time. Make your voice heard. This is your market, not GXS’s.


Todd Gould
Loren Data Corp.

June 5, 2013

Response to Todd

First they came for the communists,
and I didn’t speak out because I wasn’t a communist.
Then they came for the socialists,
and I didn’t speak out because I wasn’t a socialist.
Then they came for the trade unionists,
and I didn’t speak out because I wasn’t a trade unionist.
Then they came for me,
and there was no one left to speak for me.
– Martin Niemöller

June 8, 2013

Letter to Todd from
Earl Wertheimer

(reprinted in entirety because it is really cool)

I read both documents and wanted a better understanding of the following:

“Daisy chaining is a practice of having one EDI service provider enabling
downstream EDI providers which all become dependent on one connection.”

If I understand this correctly, you (EDI service provider) can enable me
(downstream EDI provider) to setup my own EDI VAN.

Essentially, if I want to create an EarlVAN, you (Loren) can set me up.

All traffic flows from my clients, through EarlVAN, across to Loren then
out to other VANs. I would assume that EarlVAN is a virtual entity,
connected to Loren.

Is this the practice they want to eliminate?


June 8, 2013

Response by Todd to Earl,

(reprinted in entirety because it is really cool)

The short answer is, yes, that is the practice that they want to eliminate or more specifically control and have sole authority over. This is the practice that SPS Commerce, DiCentral, CovalentWorks, NetEDI, and nearly every single other service provider (a VAN without interconnects) has been doing since EDI began, whether it is through ECGrid, Liaison, Easylink, etc.

You can call it EarlVAN or EarlTheServiceProvider (a la SPS, CovalentWorks, DiCentral). This has been how EDI has been operating since before the internet…we used to call them a VAN if they directly interconnected, and a VAS if they connected through a VAN.

GXS’s excuses about latency, lost data, etc. is pure fabrication. These virtual VANs or Service Providers provide multi-tenant systems as opposed to single-tenant end-user configurations. The data travels the exact same path over the same number of hops (or lack of them). In fact, using a service provider such as EarlVAN is frequently more reliable and responsive than one-system-per-vendor model because you know what you are doing and are getting paid to do it well, for many companies, in the same way.

GXS is taking the position that there can be service providers or virtual VANs in the market, but they must all connect directly and pay GXS to play. GXS then can exercise the right to not do business with any service provider they feel is a threat. By prohibiting that traffic over other other VANs, and refusing to connect directly (or making egregious demands to do so, such as in our case), GXS exercises the power prohibit any company it choses from competing in this market.

Additionally, GXS is now moving to enforce its “no third party/daisy-chaining” provision of their interconnect agreements, prohibiting all the other VANs from selling connectivity to GXS customers to EDI Service Providers. GXS now demands that all the traffic that goes to GXS customers is theirs alone to charge for, both ways, all sides. The other VANs should be quite concerned right now as that EDI Service Provider traffic is a sizeable chunk of billing they are about to lose.

Will the VANs lose their Interconnects to GXS for all traffic next?


June 9, 2013

By Ajay Sanghi, Managing Director
EDiSPHERE Software Private Limited

215, Congress Nagar, Nagpur 440012 | India

(reprinted in entirety because it is really cool)

We, at EDISPHERE Software Private Limited in India, are outraged by GXS plans to terminate interconnect agreement with Loren Data. This will adversely impact our business and that of thousands of companies.

We have launched India’s first indigenous self-service data integration network startup (anytoany.com), after several years of hard work, and significant investment in building the product, including native integration with Loren Data, as gateway, to our customer’s trading partners, who are spread across different EDI VANs.

The concerns highlighted by GXS in terminating the interconnect agreement with Loren Data states, “GXS will no longer process these transactions with Loren Data given concerns regarding tracking, latency, security and the daisy chaining of EDI data.” This is insincere and calculating for the following reasons:

The entire “daisy-chain” theory of GXS is a false premise for cancelling the interconnect agreement with Loren Data. Whether the data is processed by a third party service provider attached to ECGrid, or an end-users own mapping/translation software attached to ECGrid, the data moves with the same tracking, latency and security; as is being done by EDI VANs for several years.

Further, this looks like a classic CLEC vs. ILEC battle in telecom space a decade back! To me it’s a clear case of GXS (ILEC), an 800lb gorilla, muscling it’s way into crushing not just competition but also innovation, as it’s only on account of Loren Data (CLEC) that a small service provider like us can think of providing global connectivity. Loren Data is a great innovation in commoditizing the VAN business and we urge the US Supreme Court to bar GXS from cancelling Loren Data’s interconnect agreement, as the cancellation of the agreement is neither in the interest of end customer or small the service provider businesses like ours.

We will explore our options in India of stopping GXS disconnect Loren Data as our business gets directly affected by it.

I hope others also join in voicing against GXS!

Thank you for your consideration.


Ajay Sanghi

June 10, 2013

By Michael Kotoyan – Founder & Instructor EDI Academy –

(reprinted in entirety because it is really cool)

The daisy chain excuse by GXS is the most ridiculous one that I have ever heard, GXS does not even have the guts to tell the real reason (revenge for the retail catalog issue). Read more below.

When GXS bought a good EDI company called Inovis, EDI folks hoped for the best, some where sure that GSX would change their name considering how much bad publicity there is with it.  A once well-known TrustedLink translator or a  BizManager communication tool has been polluted with GXS’s brand. When GXS acquired Inovis they monopolized the retail EDI Catalog industry.

Loren Data stood up against the monopolization strategies of GXS in regards to the retail cataloging after the Inovis acquisition and  now GXS is punishing them for speaking out. After the GXS acquisition of Inovis, InterTrade (a good VAN / catalog company based out of Canada) is now there to offer an alternative to the retail EDI catalog. If Loren Data had not
spoken out about this, GXS would have a close to 100% of the retail EDI catalog business in the USA.

I am going to make sure that hundreds of EDI Academy class attendees that are confirmed to attend our classes rest of this year alone will know about this issue. When I was an EDI manager at a national retail chain back in the early 2000s I was disgusted with what GXS did to ICC.NET/EasyLink by cutting them out of the interconnect.  It was disruptive to the supply chain to thousands of vendors and there was outrage in the industry. They let ICC return to the interconnect several months later after industry outrage and a complaint filed with the department of justice http://www.justice.gov/atr/contact/newcase.html).

EDI Academy has been providing EDI Fundamentals & Best Practices Trainingfor over 6 years to thousands of EDI Professionals worldwide. Some of these attendees are GXS Customers.

As an EDI Academy instructor I have been teaching against bad EDI practices (e.g. issues caused by poor quality testing in on-retail boarding programs and testing fees) for years and always mention the ICC / GXS saga of the early 2000s in all of my classes. I tell the story of how ICC was brave enough to stand up against GXS and Sterling and route its traffic temporarily through the IBM. I am not shocked that they have now done this to Loren Data.

GXS bullies its ways to the top executives of organizations that are not as aware of what’s going in the industry. I praise Loren Data Corp for standing up against their monopolizing antitrust-like business practices.

By the way, GXS executives, in case you are actually reading this email, please note the fact that most GXS customers that take an EDI Academy class constantly complain about your outages. The tendency is that they are in a way simply “stuck” with your service because it has “just been there for years”. I know the GXS bottom line looks strong and your sales are doing well so you may not really care. However, if you think you do not have any industry-wide reputation issues you are being ignorant and living in a bubble.

Hopefully if the industry again puts enough pressure on GXS they will let Loren Data back in, just like they let ICC.NET back into the network over 10 years ago.

Todd Gould and GXS a.k.a. David and Goliath


Well the David and Goliath battle continues. See the letter below. We all hope David can find a stone for his slingshot and get the giant between his you-know-whats.

GXS to Terminate Loren Data Interconnects

Marina del Rey, California – June 4, 2013 – GXS has begun notifying its customers of its intention to terminate connectivity to Loren Data’s ECGrid® EDI Network on March 4, 2014. GXS has posted this notice on its website: Interconnect Service Announcements (http://ow.ly/lERIw — if that link is broken, another copy of the notice can be found at http://tinyurl.com/kyv2x55). Additionally, Steven Scala, Senior Vice President Corporate Strategy and Development, has informed Loren Data that its ECGrid Service Provider customers must negotiate new connections directly with GXS and will not be allowed to move their accounts to any other VAN.

Loren Data disputes all allegations of that notice, including the misinformation claiming any part of this egregious act was negotiated with Loren Data. Any service issues mentioned in the GXS advisory are self-serving and falsely attributed to ECGrid. The uptime, visibility, accuracy and reliability of ECGrid are among the top in the industry. GXS’s refusal to establish industry standard interconnects between the competing networks since 2001 has forced excessive and unnecessary support burdens and expenses on Loren Data and on trading partners of both systems. GXS’s attempt to frame this as anything other than an anticompetitive attack on Loren Data and its customers is disingenuous.

Todd Gould, President of Loren Data, comments, “Far greater than the termination of the ICC interconnect by GXS in 2002, this is an unprecedented act of monopolistic power to control and eliminate competition in this market. The fundamental premise of EDI is to allow each trading partner to pick the solution provider and system that best suits its needs, not the one that best suits GXS.

“The list of actions taken by GXS against all EDI service providers, and Loren Data as a VAN for service providers, demonstrates a long and concerted effort to prevent new competition from entering the industry by controlling interconnects. These are the same interconnects that GXS enjoyed for its own benefit, and could not live without, through the early years of EDI.

“The acquisitions of both the IBM and Inovis VANs allowed GXS to acquire enough subscribers on its system to become an essential facility to connect to for all other EDI providers. GXS is now exploiting this purchased monopoly position to knock competition out of the market, rather than competing with better-valued products to win customers. How the GXS-Inovis merger survived a Hart-Scott-Rodino review in 2010 will always puzzle me, but with 20/20 hindsight it is clear that the merger should never have been allowed.”

Gould continues, “With over 1,000,000 mailbags successfully processed between GXS and Loren Data in May 2013 alone, it is unconscionable the amount of chaos and instability this latest move by GXS will create in the market.”

In response to GXS’s newest attempt to coerce its customers’ trading partners to sign up with “GXS-approved” providers or GXS directly, Loren Data is now offering end-users unprecedented direct access to ECGrid. This will insure continuity to the more than 12,000 trading partnerships that GXS is determined to disrupt. Any companies interested in taking advantage of this offer should contact Loren Data at gxs.alternative@ecgrid.com.

Loren Data continues to pursue all legal and administrative avenues available in addition to industry outreach. A Petition for Writ of Certiorari was submitted to the U.S. Supreme Court (No. 12-1273) on April 23, 2013 for the antitrust case of Loren Data Corp. v. GXS, Inc. Please contact Thomas Kettenmann (tkettenmann@LD.com) for access to the entire case history and any legal inquiries.

Loren Data’s ECGrid system is the preferred network for more than 10,000 trading partners, the majority of which are on major service providers such as SPS Commerce, CovalentWorks, NetEDI, EC InfoSystems, Radley Corporation, Pinnacle Data Systems, DiCentral and others. ECGrid currently services their customers’ 30,000+ trading partners on over 100 different systems including VANs, X.400 networks and direct connections. ECGrid is the only system developed specifically to meet the needs of EDI service providers, delivering the tools, visibility and reliability necessary to be a backbone EDI routing network. The industry leading ECGridOSSM web services API allows developers to deeply integrate EDI applications on top of the powerful ECGrid infrastructure. See http://www.LD.com and http://www.ECGridOS.com for more information.

ECGrid is a registered service mark and ECGridOS is a service mark of Loren Data Corp.


Kristine Finlay
Ph: +1-310-491-0380

Todd Gould’s Anti-Trust Court Case


Todd Gould has penned an important status update regarding Loren Data Corp v. GXS, Inc. The case has ramifications that cut to the heart of the Interconnected VAN industry. The progress of the  case from district court to the 4th Circuit (Court of Appeals), affords us a profound opportunity to re-examine the Antitrust laws, and how the modern Jurist strives to comprehend the many  subtle issues impinging upon an (unregulated) interconnected market, i.e., VAN messaging.

Please note that within Todd’s blog post, is a link to the Petition for Rehearing.  Read the post and click through to the petition –  be connected to the truth and the facts.

This case is a “David & Goliath” story. Let’s hope history repeats itself.