Differences between Electronic Transactions Act 1998 and Electronic Transactions Act 2010

With the enactment of the Electronic Transactions Act (ETA) 1998, Singapore became the first in the world to implement the UNCITRAL Model Law on Electronic Commerce, and is widely acknowledged as a world leader in laws relating to electronic commerce and ICT. Besides provisions for creating a commercial code for e-commerce transactions, the 1998 ETA also contained clauses on the government use of electronic applications, the limitation of liability of Network Service Providers, as well as set out a framework for Public Key Infrastructure (PKI).
The United Nations Convention on the Use of Electronic Communications in International Contracts (UN Convention), adopted by the General Assembly of the United Nations on 23rd November 2005, drew upon the rules contained in the UNCITRAL Model Law and is intended to supersede it. One of the main drivers for the UN Convention was that the current Internet environment is vastly different from the predominantly EDI environment in 1998, when the UNCITRAL Model Law on Electronic Commerce was issued. Following the adoption of the UN Convention, IDA together with the Attorney-General's Chambers (AGC) conducted a review of the 1998 ETA, culminating in the 2010 ETA.
The 2010 ETA, in aligning with the UN Convention, largely retains the legal scheme for dealing with electronic transactions contained in the 1998 ETA. There are a number of details that are changed, in order to provide greater flexibility and to keep up with technology changes.
The main differences between the 1998 ETA and the 2010 ETA are summarized below:
1. Application and Consent: Clause 5 of the 2010 ETA clarifies that parties still have autonomy on deciding to exclude or agree to the use of electronic transactions, or to agree to additional requirements as to the form or authentication of a contract or transaction. The agreement or consent to the use of electronic transactions was also clarified to be inferred from the conduct of the parties unless otherwise agreed or provided by law.
2. Electronic Originals: Clause 9 of the 2010 ETA provides that a requirement in law to provide or retain certain documents, records or information in its original form can be fulfilled by retaining them in the form of electronic records, subject to certain safeguards. A public agency may impose additional requirements for the electronic originals under its jurisdiction. The Minister may exclude certain laws from this provision.
3. Time and Place of Dispatch and Receipt: Clause 13 of the 2010 ETA modifies the current rules in Clause 15 of the 1998 ETA on when and where an electronic communication is deemed to have been dispatched or received. The new rules are a better fit for internet communications, where communications can move from one email server to another, as opposed to the rules in the 1998 ETA which were created in the time of closed systems.
4. Invitation To Make Offers: Clause 14 of the 2010 ETA clarifies that an electronic communication proposing to conclude contracts and is addressed to the world at large (e.g. website advertising prices of goods) is considered an invitation to make offers, not offers capable of immediate acceptance, unless it clearly indicates the intention of the party making the proposal to be bound in case of acceptance.
5. Automated Message Systems: Clause 15 and 16 of the 2010 ETA facilitates the use of automated message systems. Clause 15 clarifies that contracts formed through the use of such systems (e.g. when a seller instructs a computer to accept an order for a product so long as there is enough stock) are valid and enforceable, even though no natural persons had reviewed the action of the systems or the result. Clause 16 allows for errors made in an electronic communication to be able to be withdrawn by the error-maker if the error was made by a natural person and an automated message system, and the system does not allow the person to correct the error.
6. Technology Neutrality: Part IV of the 2010 ETA has been amended to be technologically neutral. Technology-specific provisions based on the public-key infrastructure (PKI) have been shifted into the Third Schedule of the ETA, opening the possibility of the 2010 ETA being applicable to other security procedures like biometrics.
7. E-Government: Part V of the 2010 ETA clarifies that public agencies are empowered to accept in electronic form the filing of documents, provision of information, creation or retention of documents and originals, and the issuance of permits and payments, without having to amend their present legislations.

For more information on changes made between the 1998 ETA and the 2010 ETA,

Moving a data center? Avoid these four career-limiting mistakes

By Irwin Teodoro, Network World
August 30, 2010 10:26 AM ET

This vendor-written tech primer has been edited by Network World to eliminate product promotion, but readers should note it will likely favor the submitter's approach.

Moving a data center is a major undertaking for most organizations. And a successful move is a nice resume builder for any IT professional. A successful move will showcase skills in large-scale project planning, project management, technology integration and interpersonal communications. The process provides a chance for exposure across the company, as virtually every department is touched by the IT organization (and affected by a data center move) in some way.
However, data center moves can be fraught with career-limiting failures. No IT professional wants to be on the receiving end of memos and discussions describing lost orders, missed deadlines or customer dissatisfaction that occurred because some mission-critical business process was disrupted by a data center move that didn't run smoothly.
In most relocation projects, there are four critical mistakes to avoid: ignoring the data, combining the move with additional projects, failure to plan appropriately and not creating an inventory of equipment, applications and processes. Taking time up front to think through each of these will significantly improve your chances for success -- and the personal recognition that follows.
* Ignoring the data. While IT professionals give plenty of thought to the infrastructure involved in data center relocation, moving the data itself can be just as taxing -- sometimes even more so. It is easy to lose sight of the data, as many firms have adopted the model that business group leaders own their data. Marketing owns the prospect data base, operations owns inventory data and so on. Yet the reality is that the data and its underlying infrastructure must be considered as part of an interconnected holistic system -- not elements that can be taken apart and easily reassembled at will.
The smart IT professional will reach out to business owners before the move to identify information that may be affected and reach agreement on such items as data access, compatibility with new systems, application migration and others. Cleansing data prior to the move may be worthwhile, but definitely not during the move.
* Combining the move with additional projects. With all the planning that goes into moving a data center, many professionals attempt to combine other projects -- often guided by the CFO's visions of cost savings -- into the relocation.
This is probably the biggest mistake a firm can make. One of our clients recently attempted to combine multiple projects into a garden-variety data center move, and wound up making the project so complex that the timelines slipped out past all available slack in the plan. The firm was subject to significant financial penalties by failing to vacate the old facility on time.
Moving a data center is a major project in and of itself. It is not the time to take on virtualization of the computing environment, or incorporation of a new tiered storage philosophy. Move your data center first. If your operations or finance teams insist on trying to combine projects, work with your vendor or reseller on a quote for sequential projects -- the fees should not be significantly more. Finally, calculate potential costs associated with the increased complexity of combined projects. Paying an extra month's rent or failure-to-vacate penalties may wipe out any projected savings from the combined projects.
*Incomplete planning. Some IT professionals don't take the time or effort to prepare a comprehensive plan or complete documentation of their existing data center environments. They either go from memory about which applications run on which servers, or make incorrect assumptions on equipment that may or may not be in use. Relying on memory practically guarantees that a key server or application won't get moved correctly.
Smart project managers take a comprehensive approach to planning; not only working a baseline "best case" plan to accomplish the project goals, but putting significant upfront time into risk management planning. Most failures are due to a lack of foresight -- nobody thought the disaster that just hit your datacenter move could happen. Therefore, you didn't plan for it.
Spend the time and meet with business owners across the organization and your IT team. Identify some of the worst-case scenarios that could occur in your data center move. When you think you've identified them all, brainstorm some more. Assess the likelihood of each scenario and the potential business impact and make contingency plans. Disasters may not happen, but you'll be in a far better place if they do.
* Forgetting to create a complete inventory. It should go without saying that any IT professional worth his salt will have developed strong project plans, with plenty of slack time. However, don't forget to develop a comprehensive inventory of every server, application, networking connection, storage array and everything else in your data center before you start to move. Work with business leaders across the enterprise to make sure you include everything. And be certain to have a well-documented list of everything in the current data center before planning for a new one.
Being lax or unprepared in moving data could have devastating results. While company expectations are high for improved performance from a new infrastructure environment, data quality may suffer if it is quickly moved as an afterthought. At best, critical data may be temporarily unavailable. At worst, records could be permanently lost. For companies that increasingly rely on data, the ramifications range from abandoned shopping carts and immediate loss of sales to long-term damage to customer relationships and company reputations.
Develop plans to relocate data with as much care as you put into hardware and building projects. And make sure you work with data owners across the enterprise. By following these recommendations, you'll wish you could move more often.
Teodoro is director of systems integration for Laurus Technologies (www.laurustech.com), a leading Midwest IT consulting and systems integration firm. Teodoro can be reached at iteodoro@laurustech.com.