secure internet payment policies

�

Secure Internet Payment PoliciesHandbook F-7 October 1999

Transmittal Letter

A. Explanation. Handbook F-7, Secure Internet Payment Policies, is a new directive toprovide the guidelines, responsibilities, and standards for development of an electronicpayment system that accepts or orders payment for goods and services via the Internet.

B. Distribution. Handbook F-7, Secure Internet Payment Policies, is available on thePostal Service Corporate Intranet at http://blue.usps.gov (see Information/Policies &Procedures/Handbooks).

C. Comments

1. Submit questions and suggestions about the content of this document in writing to:

FINANCE US POSTAL SERVICE475 L’ENFANT PLAZA SW RM 8141WASHINGTON DC 20260-5000

2. Submit questions regarding the organization or editing of this document to:

CORPORATE PUBLISHING AND INFORMATION MANAGEMENTINFORMATION SYSTEMSUS POSTAL SERVICE475 L’ENFANT PLAZA SW RM 2800WASHINGTON DC 20260-1540

D. Effective Date. This handbook is effective October 15, 1999.

Stephen M. KearneyTreasurer, Corporate TreasuryFinance

Executive Summary

iiiHandbook F-7, October 1999

Executive Summary

This Secure Internet Payment Policies (SIPP) handbook provides the UnitedStates Postal Service (Postal Service) with guidelines, responsibilities, andstandards for development of an electronic payment system that acceptspayments for goods and services by way of the Internet. This will give PostalService customers 24-hour access to Postal Service goods and servicesworldwide. The Postal Service may also decide to allow major corporatecustomers to connect their networks to the Postal Service network to supportelectronic payment for goods and services. The policies of a secureelectronic payment system ensure that any business unit that proposes toaccept or request payment over the Internet or another network does so in amanner that protects the integrity of the transaction, the integrity of theinformation, and the revenue of the Postal Service.

The policies presented here are based on two essential secure paymentprinciples:

� Protect the reputation of the Postal Service and its position of strongpublic trust and confidence.

� Ensure that the Postal Service receives all revenue that is due in anaccurate and timely manner, consistent with applicable postal laws andregulations, at the least cost to the Postal Service.

The policies specify core or minimum security requirements and architecturefor payment application servers and associated processing systems and foroutside parties. These security requirements vary in rigor as determined byvalue of the transaction, knowledge of the customer, and method of payment.A key component of the guidelines is risk, which is determined by balancingthe business needs, security mechanisms, and costs until an acceptable levelis obtained.

The policies address 12 payment types. It is important to note that some ofthe payment types discussed in this handbook are viewed as emerging orimmature technologies on the Internet. As these payment types mature, thePostal Service should update this handbook to ensure that material changeshave not been made to the payment system, cost, or security that could alterthe suitability of a given payment type for use at the Postal Service.

This handbook should be used as a guide at the beginning and throughoutthe process of developing a payment system for Postal Service products andservices sold over the Internet. It should also be used when adding apayment option to an existing Internet-based product or service. It is intendedfor use by both Headquarters and field unit staff responsible for planning anddeveloping programs that exchange Postal Service goods or services formoney over the Internet.

This handbook has been developed in response to the tremendous growth —and projections for future growth — of electronic commerce on the Internet.As the Postal Service develops new products and services to be offered overthe Internet or other networks, this handbook will provide a consistent,

Executive Summary

iv Handbook F-7, October 1999

coherent set of standards and guidelines to provide adequate revenue andinformation security protection on the Internet channel.

This policy handbook is presented in six sections:

� Section 1 outlines the framework for secure Internet payment policies.

� Section 2 provides guidance on basic security requirements that anypayment type should be required to meet.

� Section 3 identifies current regulatory requirements that must be met.

� Section 4 describes demand deposit, card-based, and new paymenttechnologies in detail.

� Section 5 lists key questions that must be answered to satisfy PostalService accounting requirements.

� Section 6 offers a risk model for payment methods that is an addendumto Handbook AS-805, Information Systems Security.

Appendices provide prototype tool kits for defining risks andcountermeasures, reviewing accounting requirements, understandingaddress verification tests, and comparing the various payment methods.

Contents

vHandbook F-7, October 1999

Contents

1 Introduction 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1 Scope 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1.1 Objective 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1.2 Framework 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1.3 Level of Security 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1.4 Legal and Regulatory Requirements 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-2 Use of This Handbook 4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-3 Definitions 5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-4 References 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-5 Acronyms 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 Baseline Security for Postal Electronic Commerce Payments 9. . . . . . . . . . . 2-1 Baseline Postal Service Internet Commerce Security 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1.1 Shopping Phase Security 10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1.1.1 Firewall and Demilitarized Zone Architecture 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1.1.2 Reverse Proxy 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1.2 Checkout Phase 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-1.2.1 Web Application Secure Sockets Layer (SSL) Use 14. . . . . . . . . . . . . . . . . . . . . . . .

2-1.2.2 Postal Service Certificate Authority and Public Key Infrastructure 16. . . . . . . . . . .

2-1.3 Postpurchase Phase 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2 Baseline Postal Network Security 20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2.1 Physical, Procedural, and Operations Security 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2.2 Configuration Management 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2.3 Firewalls 21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2.4 Routers 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-2.5 Intrusion Detection 22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2-3 Baseline Financial Network Security 23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 Regulatory Requirements 25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1 Federal Regulatory Requirements 25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1.1 Electronic Funds Transfer Act (Federal Reserve System Board Regulation E) 25. . . .

3-1.2 Federal Reserve System Bank Regulation J: Check Collection and Funds Transfers 26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1.3 Federal Reserve System Bank Regulation CC: Availability of Funds and Collection of Checks 27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1.4 Bank Secrecy Act 27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1.5 Right to Financial Privacy Act 28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-1.6 Federal Digital Signature Legislation 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Secure Internet Payment Policies

vi Handbook F-7, October 1999

3-2 State Requirements and Initiatives 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-2.1 Uniform Commercial Code (Article 4A) 29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3-2.2 UCC Draft Revisions Related to Electronic Commerce 30. . . . . . . . . . . . . . . . . . . . . . . . .

3-2.3 State Digital Signature Legislation 30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4 Payment Types and Methods 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1 Lockbox 32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.1 Transaction Description 32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.1.1 Customer Requirements for Use 33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.1.2 Postal Service Requirement for Use 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.1.3 Funds Availability 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.1.4 Cost to the Postal Service 34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.2 Suitability for Postal Service Use as an Internet Payment Method 34. . . . . . . . . . . . . . .

4-1.3 Authentication and Authorization 35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.4 Settlement Description 35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-1.5 Additional Security 35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-2 Automated Clearinghouse Debit 36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .



4-2.1.2 Postal Service Requirements for Use 38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .







4-3 ACH Credit 40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


4-3.1.1 Customer Requirement for Use 42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .








4-4 Fedwire 45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .





Contents

viiHandbook F-7, October 1999





4-5 Debit — Online 49. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .










4-6 Debit — Off-line 54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .










4-7 Credit Card 58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .










4-8 SET-Enabled Credit Card 65. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .








viii Handbook F-7, October 1999




4-9 Postal Service Postal Electronic Payment Platform Cache 70. . . . . . . . . . . . . . . . . . . . . . . . . .










4-10 Digital Cash (CyberCash example) 73. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .










4-11 Financial Services Technology Consortium 78. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .




4-11.1.3 Deposit-and-Clear Model 79. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4-11.1.4 Cash-and-Transfer Model 81. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .







4-12 Bank Internet Payment System 85. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .






Contents

ixHandbook F-7, October 1999





5 Accounting Requirements 89. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1 Accounting Requirements Design Questions 90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-1.1 Revenue Flow 90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-1.2 Payment Flow 90. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-1.3 Refunds 91. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-1.4 Cost 91. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5-1.5 Customer Service 91. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6 Risk Assessment Guidelines 93. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6-1 Handbook AS-805 Requirements 93. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-2 Identification and Analysis of Risks to Electronic Payment Systems 94. . . . . . . . . . . . . . . . . .

6-2.1 Operational Risk 94. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-2.1.1 Security Risks 95. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-2.1.2 Systems Design, Implementation, and Maintenance 95. . . . . . . . . . . . . . . . . . . . . .

6-2.1.3 Customer Misuse of Products and Services 96. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-2.2 Reputational Risk 96. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-2.3 Legal Risk 97. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6-3 Risk Analysis Guidelines 98. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix A — Payment Risk Checklist 105. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix B — Accounting Checklist 109. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix C — AVS Matrix 113. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Appendix D — Payment Methods Matrix 115. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibits

xiHandbook F-7, October 1999

Exhibits

Exhibit 1-1.2Secure Payment Principles 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2Postal Service Electronic Commerce Web Application Phases 9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1Postal Service Web Application Phases, Functions, and Security Requirements 10. . . . . . . . . . . . . . .

Exhibit 2-1.1.1Postal Service Web Application Firewall and Proxy Architecture 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1.1.2Reverse Proxy and Normal Web Browsing: A Comparison 12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1.2Checkout Phase Transaction Values 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1.2.1Establishment of an SSL Connection 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1.2.2Postal Service Web Application CA or PKI 18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 2-1.3Postpurchase Network Architecture 19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4Payment Categories and Methods 31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-1.1aLockbox Transaction 33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-1.1bLockbox Out-of-Band Transactions 33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-2.1aACH Debit Payment Model 37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-2.1bACH Debit Out-of-Band Transaction 37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-3.1aACH Credit Payment Model 41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-3.1bACH Credit Out-of-Band Transactions 41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-3.2NACHA Credit Push Internet Payment Model 44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-4.1aFedwire Transaction Payment Model 46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-4.1bFedwire In-Band Transactions 46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


xii Handbook F-7, October 1999

Exhibit 4-4.1cFedwire Out-of-Band Transactions 47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-5.1aOnline Debit Payment Model 50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-5.1bOnline Debit Card In-Band Transactions 51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-5.2NACHA Certificate Authority Pilot Payment Model 53. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4.6.1aOff-line Debit Payments Model 55. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-6.1bOff-line Debit In-Band Transactions 56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-7.1aCredit Card Payment Model 59. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-7.1bCredit Card In-Band Transaction 60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-7.1cCredit Card Out-of-Band Transaction 60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-7.3Address Verification System Matrix 63. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-8.1aSET-Enabled Credit Card Payment Model 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-8.1bSET In-Band Transaction 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-8.1cSET Out-of-Band Transaction 68. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-10CyberCash Payment Model 74. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-10.1.1aCyberCash In-Band Transaction 75. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-10.1.1bCyberCash Out-of-Band Transaction 76. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.2Bank Requirements for E-Check 79. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.3aFSTC E-Check Deposit-and-Clear Model 80. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.3bE-Check Deposit-and-Clear Out-of-Band Transaction 80. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.3cE-Check Deposit-and-Clear In-Band Transaction 81. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.4aSTC E-Check Cash-and-Transfer Model 82. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibits

xiiiHandbook F-7, October 1999

Exhibit 4-11.1.4bE-Check Cash-and-Transfer In-Band Transaction 83. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-11.1.4cCash-and-Transfer Out-of-Band Transaction 83. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-12.1BIPS Push Transaction 86. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 4-12.1.2BIPS Transaction 87. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Exhibit 6-3Risk Guidelines 99. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1-1.1Introduction

1Handbook F-7, October 1999

1 Introduction

1-1 Scope

1-1.1 ObjectiveThe objective of this handbook is to provide the United States Postal Servicewith guidelines, responsibilities, and standards for development of anelectronic payment system that accepts or orders payment for goods andservices by way of the Internet.

The Internet provides Postal Service customers with 24-hour access to postalgoods and services worldwide. The Postal Service may also decide to allowmajor corporate customers to connect their networks to the Postal Servicenetwork to support electronic payment for goods and services, which wouldbe covered by the Postal Electronic Payment Platform (PEPP). These policyguidelines should be followed to ensure that any business unit that proposesto accept or request payment over the Internet or another network protectsthe integrity of the transaction, the integrity of the information, and therevenue of the Postal Service.

This handbook has been prepared for business units that are developingPostal Service products or services to be sold over the Internet. If thebusiness unit adheres to these policies, then it can ensure that the electronicpayment system meets the minimum standards for secure payments asdetermined by the Payment Technology Policy Team and its subcommittee,the Secure Payments Subcommittee. This handbook is intended to beconsistent with, and follow, Postal Service Corporate Treasury business rulesfor all payment methods.

Notably, some payment types described herein are viewed as emerging orimmature technologies on the Internet. As payment types mature, the PostalService plans to update this handbook to ensure that material changes havenot been made to the payment system, cost, or security that could alter thesuitability of a given payment type for use at the Postal Service.

This policy handbook covers the following: 1) framework for secure Internetpayment policies, 2) basic security requirements; 3) current regulatoryrequirements; 4) demand deposit, card-based, and new paymenttechnologies; 5) key questions for accounting requirements, and 6) a riskmodel for payment methods.

1-1.2 Secure Internet Payment Policies

2 Handbook F-7, October 1999

Appendices provide prototype tool kits for defining risks andcountermeasures, reviewing accounting requirements, understandingaddress verification tests, and comparing the various payment methods.

1-1.2 FrameworkThe guidelines presented here are based on the framework shown in Exhibit1-1.2, which is based on two essential secure payment principles:

� Protect the reputation of the Postal Service and its position of strongpublic trust and confidence.

� Ensure the Postal Service receives all due revenue in an accurate andtimely manner, consistent with applicable Postal laws and regulations,at the least cost to the Postal Service.

Exhibit 1-1.2Secure Payment Principles

Secure Payment Principles

Core Security

Risk Assessment

Lock

box

AC

H D

ebit

AC

H C

redi

t

Fed

wire

On-

Line

Deb

it

Off-

Line

Deb

it

Cre

dit C

ard

SE

T C

redi

t Car

d

US

PS

Sto

red

Valu

e

Dig

ital C

ash

FS

TC

-E-C

heck

BIP

S

At an operational level, these principles can be expressed in the followingways. The first framework component is that of secure payment principles.Credit fraud rates experienced with Internet products should be very close tothe already low rates experienced by the Postal Service in other programsaccepting credit cards. The privacy of Postal Service customers is to beprotected from any and all unauthorized access and use. Transfer of funds(payments) is to be accomplished in timely manner, favorable to the PostalService, and consistent with applicable customer service standards.

The second framework component is core security. The guidelines specifycore or minimum security requirements and architecture for paymentapplication servers and associated processing systems and for outsideparties. These security requirements will be applied with varying levels ofrigor. The determination of an appropriate level is based on consideration ofsuch factors as the value of the transaction, knowledge of the customer, andpreferred method of payment. Transactions may be small and isolated (e.g.,one-time purchase of a special issue stamp) or small and often repeated(e.g., weekly purchase of postage by a small business operating out of the

1-1.4Introduction


home). Transactions may also be large and isolated or large and repeated(e.g., a major mailer). In general, as the value of the transaction increases,the required level of security also increases.

Knowledge of the customer varies from the small amount of informationcollected during a visit to a Web site to long-standing business relationshipswith major mailers. The required level of security for well-known and trustedbusiness partners will be more than for distrusted Web customers.

The desire to provide convenience to the customer dictates that a variety ofpayment methods be offered. Some, such as credit and debit, can beprovided immediately. Others, such as a lockbox and automatedclearinghouse (ACH) credit, require setup. Core security is somewhat moredifficult to tie to security, primarily because the payment product developersare already incorporating security features such as certificates.

The third framework component is the variety of payment mechanismsavailable now, or likely to be available in the near future. Twelve paymenttypes are addressed.

The fourth and final framework component is risk assessment. Risk isdetermined through a process of balancing and rebalancing business needs,security mechanisms, and costs until an acceptable level is obtained. This isa difficult area because there is no established and accepted body ofknowledge about payment fraud and system penetration in an Internetcontext. There is no experiential basis for measuring risk in terms of a rate orprobability. Guidelines that consider the types of risk, loss potential, andmanagement provide the best approach for defining security requirements foreach payment type.

1-1.3 Level of SecurityThe security policies in this handbook describe the methods of deployingelectronic payment systems in support of electronic commerce conducted byway of the Internet or other networks. The security mechanisms and riskanalysis guidelines are to be applied to electronic payment systems.Individual product managers are encouraged to apply more stringent controlsand procedures appropriate to the information or nature of the transaction.Additional measures should be undertaken in accordance with the riskmanagement methodology in Section 6 of this handbook and in Chapter 8 ofHandbook AS-805, Information Systems Security.

1-1.4 Legal and Regulatory RequirementsSeveral federal and state laws and regulations that cover a broad range oftopics from privacy to electronic commerce are significant when implementingan electronic payment platform. Although many regulations, particularly thoseprescribed by the Federal Reserve System Board, are intended to beimplemented and observed by banking institutions, they govern importantaspects of the payment process such as settlement and reporting. Paymentplatform standards described in this handbook are intended to meet the

1-2 Secure Internet Payment Policies


requirements of the following laws, regulations, and proposed regulationsdescribed in detail in Section 3:

� Handbook AS-805, Information Systems Security.

� Federal Reserve System Board Regulation E (Electronic FundsTransfer Act).

� Federal Reserve System Board Regulation J (Check Collection andFunds Transfers).

� Federal Reserve System Board Regulation CC (Availability of Fundsand Checks).

� Bank Secrecy Act.

� Right to Financial Privacy Act.

� Federal Digital Signature Legislation.

� Privacy Act of 1974.

� Computer Security Enhancement Act of 1997 (proposed).

� Electronic Financial Services Efficiency Act of 1997 (proposed).

� Electronic Commerce Enhancement Act of 1997 (proposed).

� Uniform Commercial Code — Article 4A.

Various state or local laws and regulations may also need to be consideredwhen implementing an electronic payment platform. In some cases, local orstate legislation may govern the Internet channel in the absence of federalregulations. Examination of all state and local laws and regulations is beyondthe scope of this handbook.

Additionally, various laws and regulations govern international commerceinitiatives and electronic payment systems. Many regulations are still underconsideration and have not been widely accepted. One internationallegislative initiative is the United Nations Model Law on ElectronicCommerce, still in draft. The Postal Service should draw upon itsrecommendations when considering international legal direction regardingelectronic commerce.

1-2 Use of This HandbookThis handbook has been developed in response to the tremendous growth —and projections for future growth — of electronic commerce on the Internet.As the Postal Service develops new products and services to be offered overthe Internet or other networks, this handbook will provide a consistent,coherent set of standards and guidelines to provide adequate revenue andinformation security protection on the Internet channel.

It is intended for use by both Headquarters and field unit staff responsible forplanning and developing programs that exchange Postal Service goods orservices for money over the Internet.

Use this handbook as a guide in the beginning and throughout the process ofdeveloping a payment system for Postal Service products or services soldover the Internet. Use it when adding a payment option to an existingInternet-based product or service.

1-3Introduction


1-3 Definitionsaccess control — A service or technique used to permit or deny use of thecomponents of a computer or communication system.

asymmetric cryptography — (See encryption.)

authentication — The process by which information system users andcomponents verify their identity.

(mutual) authentication — The process by which the client and the serveridentify and verify themselves to each other.

availability — The property of an information system that ensures that abona fide user can access the system whenever the user requires accesses.

Centralized Automated Processing System (CAPS) — A Postal Servicepayment processing system based on electronic funds transfers to enablebusiness customers to easily pay for bulk mailings.

certificate authority (CA) — A person or organizational unit authorized toissue digital certificates for which it can vouch as to the authenticity of thecertificate holder.

confidentiality — The property that ensures that no unauthorized user hashad access to or has viewed the system or its stored data.

data integrity — The property of an information system that ensures thatdata sent, stored, and retrieved is not altered, destroyed, or replaced byunauthorized people or computer processes.

demilitarized zone (DMZ) — That portion of the firewall architecture thatallows controlled access to selected network resources from the Internet oran unguarded network. The organization’s firewall is used to control accessto hosts inside the DMZ from the Internet and access from DMZ hosts tointernal network hosts.

digital certificate — An electronic message that identifies the certificateauthority (CA), identifies the certificate owner, contains the owner’s publickey, identifies the certificate’s operational period, contains a certificate serialnumber, and is digitally signed by the CA.

digital signature — A transformation of an electronic message usingasymmetric cryptography. A person having the initial message and thesigner’s public key can accurately determine whether the transformation wascreated using the private key that corresponds to the signer’s public key andwhether the message has been altered since the transformation was made.

electronic funds transfer (EFT) — The process of transferring money fromone financial organization to another using an automated clearinghouse.



encryption — The process of transforming useful data (plain text) intogarbled data (cipher text) using a key. Symmetric cryptography uses a singlekey for the sender and receiver. Asymmetric cryptography uses a public keyfor the sender to generate the cipher text, and the receiver uses a private keyto decrypt the cipher text into plain text. The only key that can decrypt thecipher text encrypted by a public key is the corresponding private key.

encryption strength — A measure of the properties of an encryption methodthat is based on:

� The secrecy of the key.

� The difficulty in guessing the key.

� The susceptibility of the method to attack by way of back doors (poorprogramming or design), plain text attack (attempts to decrypt amessage if the attacker knows a portion of the message), and othercryptographic techniques.

issuing authority — The person or organization that issues, revokes, orsuspends a digital certificate.

key — A set of characters used to change plain text into cipher text and thereverse.

key pair — The keys used in asymmetric cryptography. The public key isused to verify that a digital signature was created using the correspondingprivate key. A private key is used to decrypt the information encrypted usingthe corresponding public key.

legal risk — A risk arising from either violations of, or nonconformance with,laws, rules, regulations, or prescribed practices or when the legal rights andobligations of parties to a transaction are not well established.

operational risk — A risk arising from the potential for loss due to significantdeficiencies in system reliability or integrity.

proxy server — An application that acts as an intermediary between a user’sdesktop World Wide Web (WWW) browser and the Internet. A proxy serverallows the organization to control access to Internet resources from a singleserver or set of servers.

reputational risk — A risk of significant negative public opinion that resultsin a critical loss of funding or customers.

reverse proxy — An alternate use of a proxy server to regulate access toselected network resources inside the organization’s protected network. Thereverse proxy acts as an intermediary between Internet clients and theprotected host, allowing the controlled exchange of sensitive information andpreventing direct access to the organization’s critical information hosts byInternet users. Reverse proxies can also provide load balancing for heavilyused servers.

smartcard — A small electronic device (about the size of a credit card) thatcontains electronic memory and possibly an embedded integrated circuit (IC).Smartcards containing an IC are sometimes called integrated circuit cards(ICCs).

symmetric cryptography — (See encryption.)

1-5Introduction


1-4 ReferencesBernstein, Terry; Bhimani, Anish B.; Schultz, Eugene; and Siegel, Carol A.,Internet Security for Business, 1996.

Cheswick, William R. and Bellovin, Steven M., Firewalls and Internet Security,1994.

CyberCash World Wide Web site, http://www.cybercash.com, August 1998.

Elgamal, Taher, “Commerce on the Internet,”http://www.netscape.com/newsref/std/credit.html, July 14, 1995.

Financial Services Technology Consortium World Wide Web site,http://www.fstc.org, September 1998.

Ford, Warwick and Baum, Michael S., Secure Electronic Commerce, 1997.

Garfinkel, Simson, and Spafford, Gene, Web Commerce and Security, 1997.

GTE Internetworking, “Overview of Cryptography Used in the FSTC U.S.Treasury Electronic Checking Market Trial,” http://www.fstc.org, June 1998.

O’Mahoney, Donal; Peirce, Michael; and Tewari, Hitish, Electronic PaymentsSystems, 1997.

United States Postal Service, Handbook AS-805, Information SystemsSecurity, April 1994.

United States Postal Service, Handbook F-1, Post Office AccountingProcedures, November 1996.

Forrester Research.

Gartner Group Research.

National Automated Clearinghouse (NACHA) Publications.

Price Waterhouse Global Technology Centre, Technology Forecast, 1998.

Tower Group Research Notes.

1-5 AcronymsACH automated clearinghouse

AIC account identifier code

API application program interface

ASC Accounting Service Center

ATM automated teller machine

AVS Address Verification System

BIPS Bank Internet Payment System

BMEU business mail entry unit

CA certificate authority

CAPS Centralized Automated Processing System



CC credit card

CMRS Computerized Meter-Resetting System

CRL certificate revocation list

DDA demand deposit account

DES data encryption standard

DMZ demilitarized zone

DNS Domain Name Service

DoD Department of Defense

ECWS electronic commerce Web server

EDI electronic data interchange

EFT electronic funds transfer

EPH electronic payments handler

FDMS First Data Merchant Services

FSTC Financial Services Technology Consortium

GLA general ledger account

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol–Secure

IP Internet protocol

ISO International Standards Organization

ISSCS Information Systems Service Center

LAN local area network

MNASC Minneapolis Accounting Service Center

NACHA National Automated Clearinghouse Association

NPP Network Payment Protocol

NSF not-sufficient funds

ODFI originating depository financial institution

PEPP Postal Electronic Payment Platform

PI payment instruction

PIN personal identification number

PKI public key infrastructure

POS Point of Sale or Point of Service

PSF Postal Service Fund

PSFR Postal System Financial Report

RA registration authority

RDFI receiving depository financial institution

SET Secure Electronic Transaction

SSL Secure Sockets Layer

SSLv3 Secure Sockets Layer, version 3

TCP transfer control protocol

URL Uniform Resource Locator

2Baseline Security for Postal Electronic Commerce Payments


2 Baseline Security for PostalElectronic Commerce Payments

The Postal Service is actively developing interactive Web sites that permitcustomers to complete transactions by way of the Internet and to providepayment information online (see Exhibit 2). To ensure that these transactionsoccur securely and protect the customers’ information and the PostalService’s information, revenue, and brand, the Postal Service needs toestablish guidelines to integrate an electronic payments system with currentand future Postal Service Internet commerce offerings.

Exhibit 2Postal Service Electronic Commerce Web Application Phases

Shopping Phase:

Customer

Internet

Back-End ElectronicPayments Platform

USPS Web Server

� No encryption� Server (host) protection

Checkout Phase:� Server authentication� Strong encryption� Customer authentication

Postpurchase Phase:� Protect customer

payment information� Protect transaction records



2-1 Baseline Postal Service Internet CommerceSecurity

A Postal Service electronic commerce Web application requires transactionsthat comprise three principal phases: shopping, checkout, and postpurchase.Each phase requires different information security architectures to protect theinformation. The functions and required security mechanisms of each phaseare described in Exhibit 2-1.

Exhibit 2-1Postal Service Web Application Phases, Functions, and SecurityRequirements

Phase Function Security

Shopping The customer selects items to bepurchased.

� Integrity� Availability

Checkout The customer provides payment forthe items selected.

� Confidentiality� Integrity� Authentication� Availability

Postpurchase The Postal Service settles andreconciles the transaction and storesthe transaction information (thecustomer’s private paymentinformation, transaction number,etc.).

� Confidentiality� Integrity� Authentication� Availability

Note: Registration, which is outside the scope of this handbook, mayinclude sensitive information about customers and should have the samelevel of security as checkout.

2-1.1 Shopping Phase SecurityThe shopping phase is the period during which the customer selects theproducts or services to be purchased. The critical security elements of theshopping phase are integrity and availability. Online catalogs of products arepublicly available and do not require encryption to protect them from view;however, the integrity of the information presented to the customer must beprotected.

Online service and product selection information typically relies on graphicsfiles to convey the attributes of the service or product. Use of encryptionduring this phase would significantly slow the processing time for theseapplications; however, this part of the Postal Service Web applicationrequires adequate protection from Internet vandals to ensure the integrity ofthe catalog and the Postal Service’s name and reputation. Adequate networkbandwidth, server performance, and redundancy are required to ensure thatthe Web application is available for customer use. The following measuresprotect the integrity of the shopping phase server.

2-1.1.2Baseline Security for Postal Electronic Commerce Payments


2-1.1.1 Firewall and Demilitarized Zone Architecture

Protection of the Postal Service catalog requires protection of the cataloghost server to ensure availability and integrity. The Postal Service shouldimplement a multi-homed firewall architecture at its Internet commerce sitesand install a catalog server (when necessary) in a demilitarized zone (DMZ)of the firewall (see Exhibit 2-1.1.1). Redundant hardware operating in ahot-standby mode for the critical elements is recommended based onbusiness needs for contingency planning and data backup.

The firewall should allow only HTTP port 80 connections to the shopping Webserver. If the shopping Web server is also the checkout server, then HTTPSport 443 connections also have to be allowed. An additional layer of securityand functionality can be included through the use of a reverse proxy in theDMZ of the firewall to the shopping cart server either in the DMZ or in theinternal Postal Service network.

Exhibit 2-1.1.1Postal Service Web Application Firewall and Proxy Architecture

Public Networks

USPS Private Network

Proxy ServerUSPS PublicWeb Server

(Catalog Host)

USPS WebApplication

Internet Firewall

USPSNetwork

USPS FirewallDemilitarized

Zone

2-1.1.2 Reverse Proxy

A reverse proxy provides additional security by introducing another hostbarrier between a potential hacker and the real Postal Service Webapplication. To help understand this, a comparison of normal Web browsingto reverse proxy browsing is provided (see Exhibit 2-1.1.2).

2-1.1.2 Secure Internet Payment Policies


Using reverse proxies provides two important advantages for electroniccommerce Web servers:

� Only the proxy server is visible and thus vulnerable to Internet-basedattacks. The Postal Service Web application itself is not visible to theInternet. Only the proxy server is permitted to talk through the firewall tothe Web application platforms, and only using HTTP protocols.

� It allows for the use of multiple Web servers, which improves availabilityand provides load-balancing features.

Exhibit 2-1.1.2Reverse Proxy and Normal Web Browsing: A Comparison

Normal Web Browsing

When a customer visits an e-commerce site directly, the customeraccesses the site by way of a Uniform Resource Locator (URL):http://www.company_store.com/index.html.

The Domain Name Service (DNS) resolves host.company_store.com tothe IP address of www.company_store.com. This IP address is requiredto establish a TCP connection on port 80 between the customer Webbrowser and the company_store.com Web server. Once a connectionbetween the customer and the company_store.com is made, the Webpage is accessed using the HTTP GET command: GET/index.html.

The host name is stripped from the request because there is anestablished TCP connection between the customer browser and thecompany_store.com Web server. This results in the Web browserretrieving the document directly from the company_store.com Webserver.

Reverse Proxy Web Browsing

When a reverse proxy is used, the domain name of the store is set to theproxy server, and the actual commerce server might becommerce.company_store.com. The customer would access the URL asbefore: http://www.company_store.com/shopping/index.html.

When the reverse proxy receives the request, it directs the HTTPrequest to the internal commerce.company_store.com host and providesthe HTTP reply. The customer doesn’t realize that the proxy servercontrols the information flow. The customer browser connects to port 80of the proxy server. The customer browser then makes an HTTP GETrequest: GET /index.html.

The reverse proxy now applies one (of possibly several) URL mappings(associations between actual servers and names). The shopping isreplaced with http://commerce.company_store.com, and the proxyretrieves the index.html document and relays it to the customer Webbrowser. The customer is never aware that the request was made andfulfilled by the proxy server.

2-1.2Baseline Security for Postal Electronic Commerce Payments


2-1.2 Checkout PhaseThe checkout phase involves the exchange of payment and shippinginformation from the customer to the Postal Service. There are four criticalsecurity elements of this phase:

� Confidentiality.

� Integrity.

� Authentication.

� Availability.

Confidentiality is required to protect the customer’s private paymentinformation and to prevent theft and fraud. Integrity of the transaction isrequired to ensure that the transactions arrive at the Web application withoutalteration by a third party. Authentication (identification) is required to ensurethat the customer can trust the Postal Service Internet Web site to be PostalService and not a fraudulent imposter; authentication also ensures that theidentity of the customer is known with a large degree of certainty. Availabilityensures that the Postal Service can collect payment information and revenueanytime that the shopping phase server is available for use; backup serversand network connection paths are essential to ensure that transactions canbe processed.

During the checkout phase, the customer provides payment and shippinginformation for the product and service selections made during the shoppingphase. Once the customer provides the payment information, a transactionID number is assigned to record the details of the transaction. The checkoutphase requires additional security measures to protect the privacy of thecustomer and prevent misuse of payment information. The securityarchitecture for the checkout phase implemented by the Postal Servicedepends on the value and type of transaction required (see Exhibit 2-1.2).

Exhibit 2-1.2Checkout Phase Transaction Values

ValueType Value Criteria

AuthenticationRequirements

ConfidentialityRequirements

Low Less than $100 � Strong Postal Service server authentication

Strongencryption

Medium Equal to or greaterthan $100 and lessthan $3,000

� Strong Postal Service server authentication� Customer registration

Strongencryption

High Equal to or greaterthan $3,000

� Strong Postal Service server authentication� Strong customer authentication

Strongencryption



For low-value transactions, confidentiality is required to prevent attackersfrom stealing credit card numbers as they are passed over the Internet.Customer registration may be required for low-value transactions in certaincases (for example, when Federal Aviation Agency (FAA) regulations requirethe Postal Service to know the customer before accepting a package heavierthan 16 ounces). For medium-value transactions, customer registration anddata confidentiality are required. Velocity checking may be necessary for low-and medium-value transactions to protect against fraudulent use of somepayment types. For high-value transactions and purchases requiringidentification of the customer, strong mutual authentication (using customerdigital certificates, for example) and confidentiality are required.

The Postal Service Web application checkout phase should use a SecureSockets Layer (SSL) to provide the following:

� Strong authentication to the customer of the Postal Service serverthrough the use of server certificates (all purchase transactions).

� Strong encryption between the customer’s browsers and the PostalService server (all purchase transactions).

� Customer registration to comply with know-the-customer laws regardingthe prevention of money laundering (medium-value transactions).

� Strong authentication of the customer to the Postal Service server(high-value transactions only).

The Postal Service Web application platform participating in the checkoutphase should be set up in a secure manner similar to that of the shoppingserver with respect to availability and integrity.

2-1.2.1 Web Application Secure Sockets Layer (SSL) Use

SSL provides two functions for Internet-based electronic commerce: (1) confidentiality through the use of encryption and (2) authenticationthrough the use of digital signatures. Digital certificates are required on theserver to support SSL. The determinant for what key length is acceptable isto be informed by policy determinations by the U.S. Department ofCommerce, Bureau of Export Administration. Given current regulations, forcustomers accessing the Web application from within the United States,server-side SSL should be implemented using at least a 128-bit-length key(strong encryption) to ensure that Internet hackers cannot easily conduct abrute force attack (repeated attempts using every possible key value) againstthe security. The option to use only strong encryption may prevent the use ofthe Postal Service Web application by customers who have browsersincapable of supporting 128-bit-length keys and by foreign national users(because of export restrictions).

The checkout server can be configured to establish encrypted sessions usingstrong encryption or export grade encryption (56-bit is the standard keylength, but available products currently use a 40-bit-length key), dependingon the capability of the customer’s browser. The key length acceptable forexport may change; therefore, internal Postal Service customers shouldconsult the latest regulations of the U.S. Department of Commerce, Bureauof Export Administration. In this case, the servers should provide a warning



banner prior to the submission of payment information by the customer thatindicates the use of a lower-grade encryption.

SSL provides single authentication through the use of a digital certificate bythe checkout server and mutual authentication through the use of a digitalcertificate by the customer and the Postal Service checkout server. Theserver digital certificate provides the mechanism for strong authentication ofthe checkout server to the customer; this makes it difficult for potentialattackers to set up phony Postal Service sites and to collect credit cardnumbers by pretending to be the Postal Service. Customer digital certificatesprovide a strong degree of certainty that the person presenting the digitalcertificate to the Postal Service Web application server is well known andtrusted by the Postal Service.

Exhibit 2-1.2.1 illustrates the establishment of an SSL connection between aWeb browser and a server. Each step is described in greater detail below.

1. The customer connects to a secure Web site.

2. The server asserts its site identity by presenting its digital certificate(signing its server digital certificate with its private key) and sending it tothe customer’s browser. The browser uses the server’s public key (fromthe server’s digital certificate) to verify that the owner of the digitalcertificate is the same as the one who signed it. If the digital certificateis forged, the public key will not be able to verify the contents of thedigital certificate.

3. The customer verifies the server’s digital certificate by way of atwo-step process. First, the customer’s browser ensures that thecertificate authority (CA) for the server’s digital certificate is one that itdeems acceptable. If the customer’s browser does not accept theserver’s certificate, it informs its user that the certificate presented bythe server was issued by an unknown CA. In such a case, the usermanually (visually) authenticates or rejects the certificate presented bythe server to determine that the certificate was issued by a trusted thirdparty for the exact site that the user is attempting to browse.

4. If the server requires the user to have a digital certificate to access thesite, the server requests a digital certificate from the customer toauthenticate the customer.

5. The customer chooses which personal digital certificate to present froma pull-down menu or by referring to the help file that accompanies thebrowser. Standard browsers will check the CA for the certificaterevocation list (CRL). This allows the customer to select a specificdigital certificate if he or she has multiple certificates in his or herpossession.

6. Finally, a secure channel is established between the customer’sbrowser and the server, using a session key generated by thecustomer’s browser.

7. This key is transmitted to the server in an encrypted format using theserver’s public key to encode the key prior to transmission.



Exhibit 2-1.2.1Establishment of an SSL Connection

Customer

Certificate Authority

1. Client browserinitiates connection.

Postal ServiceWeb Server

Authentication Complete

Secure Commumication with Session Key

3. Client verifiesserver ID.

5. Client passes ID(if required).

6. Client generatessession key andsends to serverwith server publickey.

2. Server replies withdigital ID and mayrequest client ID.

4. Server requestsclient ID (if required);verifies.

7.Server decryptssession key withserver private key.

2-1.2.2 Postal Service Certificate Authority and Public KeyInfrastructure

In order to support the use of customer digital certificates, the Postal Servicemust purchase digital certificates from a third party or establish a PostalService CA and public key infrastructure (PKI) to issue certificates. Thisrequires that the Postal Service trust that the CA-checking functionality builtinto the browser products from Microsoft and Netscape performs in theprescribed manner. The role of the CA is to provide the mechanism to assurethe customer that the server is authentic and vice versa. SSL providesencryption and strong mutual identification and authentication for networkconnections. For low-value transactions, only the server SSL is required(encryption and strong server identification). For high-value transactions,strong server and customer (mutual) authentication and encryption arerequired.

For low-value transactions, the customer connects to the server (by way ofthe proxy, if implemented), and the server returns its public key. The SSLidentification and authentication component is made up of server andcustomer digital certificates. Using both certificates to authenticate aconnection is called mutual authentication. It provides assurance of the



server’s identity to the customer and of the customer’s identity to the server,based upon the implicit trust that both parties have in the issuing authoritiesof both parties’ certificates. Encryption of the session is between the Webserver and the customer’s Web browser (see Exhibit 2-1.2.2).

Postal Service customers who require a personal certificate will obtain onefrom a Postal Service certificate authority and apply for a personal digitalcertificate through an appropriately defined process. To support this function,the Postal Service may have to implement a CA and PKI or establish arelationship with an existing CA. Once a CA or PKI is established, the PostalService can issue personal certificates to those customers who require strongidentification. The process of customer digital certificate issuance should berobust enough to prevent impersonation.

The Postal Service must determine the criteria that it will use before issuing apersonal digital certificate to a customer (e.g., address, social securitynumber, home phone number, and perhaps a personal phone call). ThePostal Service or its authorized agent will act as the registration authority andapprove or disapprove customer requests for certificates. When approved fora digital certificate, the customer will be notified by way of e-mail and giveninstructions on how to obtain the certificate. This involves importing thecertificate into the same Web browser that the customer used to apply for thecertificate. Once the customer is issued a certificate, the customer canrepeatedly use it until it expires. Renewal could be accomplished by requiringthe user to repeat the initial application process or use his or her currentcertificate to obtain a new one. Once a customer is issued a certificate, thecustomer will use it to access the Postal Service checkout server by way ofthe reverse proxy (if implemented). The checkout server will then be able toconduct business with its customers through the secure mechanismspresented above.



Exhibit 2-1.2.2Postal Service Web Application CA or PKI

2

1

6

1

2

3 4

5

6

7

2. SSLv3 encryptedsession established.

1. Customer initiates access; presents client certificate.

3. Web server presentsserver certificate andrequests clientcertificate.

4. Server and clientverify certificatesand digital signatures,providing strongmutual authentication.

5. USPS proxyserver in DMZrelays requeststo USPS Webapplication.

6. Customer and USPSWeb applicationconduct transaction.

7. Web applicationcompletes settlement.

Internet

DMZ

USPS Customer

USPS CA/PKI

USPSApplicationProxy

Server

FirewallUSPSPrivateNetwork

2-1.3 Postpurchase PhaseThe postpurchase phase involves transaction settlement and fulfillment.There are 4 critical elements of this phase:

� Confidentiality.

� Integrity.

� Authentication.

� Availability.

Confidentiality is required to protect the privacy of the individual and toprevent theft and fraud that can result from cases of inadequately protectedcustomer payment information. Data integrity is required to ensure that alltransactions received are processed accurately. Authentication is required toassure that the Postal Service Web application server is communicating withlegitimate, authentic, third party financial network servers. The postpurchasephase must have the availability of the shopping and checkout phases toensure that payment can be collected for goods and services ordered.

Postpurchase security is linked to the security of the Postal Network. ThePostal Network is the segment of the Web application linking paymentinformation submitted by the customer to the financial network for settlementand for submission of information to Postal Service applications that generateproduct or service orders. Exhibit 2-1.3 is a notional diagram of the majorportions of the Postal Network that will support the Postal Service Webapplication. After the customer submits payment information to the Web



application checkout server, it passes the payment information to thepayment system application server, which accomplishes the following tasks:

� Determines payment type from checkout server inputs.

� Formats payment messages for authorization or settlement.

� Requests payment authorization.

� Submits product order, if approved.

� Creates transaction records.

Exhibit 2-1.3Postpurchase Network Architecture

FirewallProxy Server

Internet

Financial NetworkConnections(settlement)

Postal Network(fulfillment)

USPS Network

Firewall Firewall

Intrusion DetectionWorkstation

Catalog Server

DMZ

CheckoutApplication

Server

PaymentSystem

ApplicationServer

IntrusionDetection

Workstation

Stored ValueAccountServer

Product OrderApplication

Server

Data Data



2-2 Baseline Postal Network SecurityIn all phases of the Internet transaction, a baseline level of security within thePostal Service must be ensured. Handbook AS-805 provides instructionsconcerning Postal Service requirements for computer systems that performcritical functions such as handling monetary payments. Requirements fromHandbook AS-805 and other considerations are described here. The systemsthat conduct the authorization and transfer of funds received for PostalService goods and services must be available in conjunction with theinterbank networks and the Postal Service Web application servers.Confidentiality includes access control to the computers and the networksconnecting the computers. The following areas should be closely examinedto determine the requirements for the operation of the payment system ofPostal Service Web applications at an acceptable risk level:

� Physical security.

� Procedural security:

– Console access controls.

– User and administrator accounts.

– Contractor personnel security.

� Operations security:

– Backups.

– Hardware maintenance.

� Configuration management:

– Operating system installation, configuration, directory, service,and file permissions.

– Application installation controls.

– Content update controls.

– Software patch installations and updates, file and directorypermissions.

– Software change detection and configuration snapshot tools.

– Virus scanning tools.

� Firewalls:

– Reverse proxy (see Section 2-1.1.2).

– Network access controls.

– Packet filtering and inspection.

– Separation of Internet, Postal, and interbank networks.

– Traffic monitoring.

– Access logging.

� Routers:

– Access controls.

– Packet filtering and logging.



� Intrusion detection:

– Active monitoring of DMZ and Web application networks.

– Logging and review of network activity.

2-2.1 Physical, Procedural, and Operations SecurityPostal Service requirements for physical security, procedural controls,configuration management, and operations are described in AS-805 andshould be followed.

2-2.2 Configuration ManagementSoftware configuration monitoring tools should be used to ensure the integrityof the hosts used to conduct electronic commerce. This includes monitoringfor computer viruses, Trojan horses, logic bombs, and other file systemattacks. There are three types of tools available: (1) snapshot tools, (2)change detection tools, and (3) virus scanners.

Snapshot tools scan the system, identify known security vulnerabilities, andestablish baseline configuration information. The snapshot tool should be runafter the initial installation and following any changes made to the system.Change detection tools look for changes to a host’s file system on a real-timebasis. Virus scanning software can also be used to check files on the host forviruses.

The following vendors provide operating system diagnostic tools, but oneshould check the Postal Service Integrated Tool Kit (ITK) to determine what iscertified for use within the Postal Service:

� Kane Security Analyst (Kane – NT and Novell).

� Enterprise Security Manager (Axent – Novell, UNIX, and NT).

� Satan (Freeware – UNIX).

� COPS (Freeware – UNIX).

� Tiger (Freeware – UNIX).

� Tripwire (Freeware – UNIX).

� Norton Anti-virus (Symmantec – NT and Novell).

� Dr. Solomon (Network Associates – NT and Novell).

� McAfee VirusScan (McAfee – NT and Novell).

The critical network elements that protect assets are firewalls, routers, packetfilters, and intrusion detection systems. The objective of the networkarchitecture and use of tools is to ensure that no unauthorized connectionsare made to the Postal Service Web servers used for the checkout phase.

2-2.3 FirewallsThe most vulnerable attack point is the Internet connection; however, eachsegment should be protected using a firewall to ensure that a compromise onany one network does not affect the others. Firewalls should ensure that onlythe proxy server could connect to the Web application checkout server (on



behalf of the customers); the only server that should be allowed to receive aconnection in the Postal Service Web application network is the checkoutserver. A similar strategy should be used to protect the other network hoststhat make up the secure electronic payment systems.

2-2.4 RoutersRouters should be configured to block or filter unwanted traffic. Routersshould also be configured to log connections to and from hosts to monitor forattempted breaches. Additional security can be achieved using switches inbetween the firewall and the DMZ servers.

Recent developments in Internet protocol switching technology have resultedin refinements of DMZ architecture designs. The employment of an Ethernetswitch in the Web application network would reduce the impact of a hostcompromise by reducing the effectiveness of packet sniffing. Switches alsoimprove network performance by providing dedicated bandwidth forhigh-speed data transfer and improved security for broadcasts. Switchingsignificantly lowers latency and increases the overall speed of data transfer.By handling domain broadcasts locally and providing a direct point-to-pointconnection, switching technology delivers data securely to the intendedrecipients.

Packet filtering is the ability of the firewall to examine IP packet headers todetermine the source packet’s origination and destination addresses and thenetwork transport service utilized. The system administrator defines blockingand forwarding filters to control access. Packet filtering is a low-cost securitytool and typically is not sensitive to application content.

2-2.5 Intrusion DetectionIntrusion detection monitoring tools are real-time attack recognition andresponse systems that provide a configurable level of protection againstcommon attacks. Most monitoring tools will detect suspicious network activityand prevent unauthorized access to the Postal Service’s data and systemresources. These products are passive software modules that do not interferewith network traffic or degrade performance. Intrusion detection products canbe configured to perform the following tasks:

� Provide real-time detection of intrusion attempts and network misuse.

� Respond to unauthorized or suspicious activity by automaticallylogging, recording, or terminating the intruder’s actions.

� Prioritization of network events by way of reporting mechanisms.

� Monitor enterprisewide networks from a central location.

� Enforce network policies such as Java and Active or X blocking.

� Enable dynamic reconfiguration of routers and firewalls based on apredefined policy.

2-3Baseline Security for Postal Electronic Commerce Payments


Monitoring software also comes in the form of diagnostic tools that can beperiodically run against various operating systems to check for vulnerableconfigurations. Appropriate times to run such tools are after any of thefollowing events:

� An intrusion has been detected.

� A new service or application has been installed.

� A system has been reconfigured.

� A system has been upgraded.

� A system has crashed.

Several intrusion detection software packages are commercially available:

� Network Flight Recorder (Network Flight Recorder Inc.).

� RealSecure (Internet Security Solutions).

� Net Ranger (Wheel Group).

� Internet Security Scanner (Internet Security Solutions – TCP or IPnetworks).

� Ballista (Ballista – TCP or IP networks).

These and other packages for host and network monitoring are available,easy to install, and easy to use. The physical network location of the intrusiondetection tools is important. The use of IP switching technology reduces thethreat of network sniffing attacks; however, it can also reduce the networktraffic seen by intrusion detection devices. To ensure adequate monitoring, anintrusion detection workstation should be placed on both the DMZ and Webapplication networks such that the intrusion detection device can monitor alltraffic.

2-3 Baseline Financial Network SecurityThe Postal Service Web application will connect payments and clearinghousenetworks to the application servers that support it. Networks connected tosupport the transfer of funds should be governed by a mutually agreed-uponand binding set of terms between the clearinghouse or settlement networkand the Postal Service. These agreements generally take the form offinancial electronic data interchange agreements, credit card and Internetpayment service provider agreements, and electronic funds transferagreements, and they are often enforced in contracts signed between parties.

The primary requirements for baseline financial network security areconfidentiality and availability. Firewalls should be installed as gateways tothe financial networks. The firewalls should be set up with strict accesscontrol rules, and all transactions should be logged. Daily checks should beused to ensure that attacks are not being made. Further security could beachieved by requiring the payment application server to use a digitalcertificate to authenticate with the payment system host prior to sending atransaction request.

3-1.1Regulatory Requirements


3 Regulatory Requirements

Although there is a considerable body of law affecting various aspects ofelectronic commerce, to date no specific federal or state law providesdefinitive guidance on payments over the Internet. Rather, laws written tocover various aspects of the electronic exchange of value have, in nopredictable pattern, been extended to the Internet. This section provides ageneral review of federal, state, and international laws thought to influenceand regulate commerce over the Internet. Where possible, the directimplications of specific laws for the Postal Service have been noted.

3-1 Federal Regulatory Requirements

3-1.1 Electronic Funds Transfer Act (Federal ReserveSystem Board Regulation E)The Electronic Funds Transfer Act (EFTA) (15 U.S.C. 1693 et seq.) wasenacted on November 10, 1978, and is implemented by Federal ReserveSystem Regulation E (12 Code of Federal Regulations 205). The EFTAcontrols the electronic transfer of funds to and from accounts within theUnited States, and it provides a basic framework establishing the rights,liabilities, and responsibilities of participants in electric funds transfer (EFT)systems. Its primary objective is to protect the rights of individual customersin their dealings with these systems, and it allocates responsibility andtherefore liability among the participants in an EFT process. The EFTAdefines an electronic funds transfer as “any transfer of funds other than atransaction originated by check, draft, or similar paper instrument which isinitiated through an electronic terminal, telephonic instrument, or computer ormagnetic tape so as to order, instruct, or authorize a financial institution todebit or credit an account.”

Examples of EFT services are automated teller machine transfers, telephonebill payments, Point of Sale terminal transfers in stores, and preauthorizedtransfers from or to a customer’s account (e.g., direct deposit of SocialSecurity payments).

Regulation E is defined under the Code of Federal Regulations, Title 12,Banks and Banking, Chapter II, Part 205 (12 CFR 205.1–12 CFR 205.15). Itestablishes the rights, liabilities, and responsibilities of parties in electronic



funds transfers and protects customers using EFT systems. Regulation Eincludes the following key provisions:

� Rules for the solicitation and issuance of EFT cards.

� Institutional requirements to disclose certain terms and conditions ofEFT services.

� Requirements for disclosure and documentation of consumer legalrights and remedies.

� Allocation of risk.

� The liability of consumers for unauthorized electronic funds transfersresulting from lost or stolen cards.

� Documentation requirements for electronic transfers (on periodic andother statements).

� Dispute resolution procedure for errors.

� Notice of crediting and stoppage of preauthorized payments from aconsumer’s account.

With respect to electronic commerce, the EFTA imposes no duty of care onaccount holders, other than requirements for prompt notification of the issuingfinancial institution about theft, loss, or unauthorized transactions noted onstatements with respect to access devices (such as credit or debit cards).The safeguarding of user IDs, passwords, authentication tokens, and digitalcertificate data is necessary in order to minimize the security risks present inan electronic payment process. These requirements are beyond the scope ofthe EFTA.

3-1.2 Federal Reserve System Bank Regulation J: CheckCollection and Funds TransfersRegulation J is defined under the Code of Federal Regulations, Title 12,Banks and Banking, Chapter II, Part 210 (12 CFR 210.1–12 CFR 210.32). Itestablishes procedures, duties, and responsibilities among Federal ReserveSystem and (1) the senders and payers of checks and other items and (2) thesenders and recipients of wire transfers of funds.

Regulation J provides a legal framework for depository institutions to collectchecks and other items and to settle balances through the Federal ReserveSystem. The regulation specifies terms and conditions under which ReserveBanks will receive items for collection from depository institutions and underwhich Reserve Banks will present items to depository institutions. Inconjunction with Regulation CC (which addresses availability of funds andcollection of checks and is discussed in the next section), Regulation Jestablishes rules under which depository institutions may return unpaidchecks through Reserve Banks. The regulation also specifies terms andconditions under which Reserve Banks will receive and deliver transfers offunds over Fedwire to and from depository institutions.

Regulation J is supplemented by operating circulars issued by the ReserveBanks that detail more specific terms and conditions under which Reserve



Banks will handle checks and other cash items, noncash items, and wiretransfers of funds.

Any and all Regulation J requirements addressed in existing banking servicesthat are used by an Internet payment vehicle are likely to already be in effect.

3-1.3 Federal Reserve System Bank Regulation CC:Availability of Funds and Collection of ChecksRegulation CC is defined under the Code of Federal Regulations, Title 12,Banks and Banking, Chapter II, Part 229 (12 CFR 229.1–12 CFR 229.43); itimplements the Expedited Funds Availability Act (EFA) and governs theavailability of funds and the collection and return of checks.

Regulation CC establishes availability schedules, as provided in the EFA,under which depository institutions must make funds deposited intotransaction accounts available for withdrawal. The regulation also providesthat depository institutions must disclose their funds availability policies totheir customers. In addition, Regulation CC establishes rules designed tospeed the collection and return of checks and imposes a responsibility onbanks to return unpaid checks expeditiously. The provisions of Regulation CCgovern all checks, not just those collected through the Federal ReserveSystem.

Regulation CC also addresses electronic presentment of checks, theavailability of funds requirement, and electronic consumer notices about theavailability of funds. It requires that consumers have access to funds the daythey are received by the depositing institution and that paper copies ofelectronic notices must be provided upon request.

Currently, there are few, if any, federal regulations that are applicable toInternet-based transactions of stored value cards. Although Mondex (whichhas implemented a chip-based stored value card in Europe and Canada andis testing it in the United States) claims that its model uses electroniccurrency, there is no recognition of this claim by any of the governingeconomic bodies within the world today. A Government Accounting Office(GAO) report (Payments, Clearance, and Settlement: A Guide to theSystems, Risks, and Issues, Chapter Report, 06/17/97, GAO/GGD-97-73)states that “conducting financial transactions over the Internet creates newopportunities for counterfeiting, money laundering, and tax evasion. Securingpayments over the Internet will involve the implementation of new andunproved security measures.”

3-1.4 Bank Secrecy ActThe Bank Secrecy Act (BSA) generally requires that bank customers benotified upon receipt of a request for the release of financial information orrecords by a government entity. In certain instances, however, the financialinstitution may not reveal to its customers that their records are beingreviewed. For example, the BSA requires that a domestic U.S. financialinstitution file a report with the U.S. Treasury Department within 15 days ofwhen it is involved in a transaction for the payment, receipt, or transfer of



U.S. currency or other monetary instruments totaling $10,000 or more. TheU.S. Postal Service is considered a domestic U.S. financial institution withrespect to the sale of money orders. In addition, there are reportingrequirements for movements of currency or other monetary instruments$10,000 or more into and out of the United States and for transactions abovecertain amounts involving foreign bank accounts and record-keepingrequirements for monetary instruments of $3,000 or more.

Failure of domestic financial institutions to comply with the reportingrequirements of the BSA may result in substantial penalties. Penaltiesassociated with negligence in relation to this regulation include monetarypenalties, which can be severe and would be imposed upon each instance ofthe violation. The BSA also contains criminal penalties for violations of anyCurrency and Foreign Transaction Reporting Act (CFTA), provisions of theBSA, or any regulation prescribed thereunder. Recent legislation providesthat if a financial institution is convicted of a criminal violation under the BSA,the government may do any of the following:

� Prevent a financial institution from transacting business in the UnitedStates.

� Terminate a state bank’s Federal Deposit Insurance Corporationcoverage.

� Prohibit a foreign bank from operating an agency, branch, orcommercial lending subsidiary.

In September 1998, the Federal Reserve System Board proposed aregulation that would require banks to undertake efforts to know the customerby developing specific identifying information and to understand normal andexpected transactions. Non-face-to-face transactions, including Internettransactions, are specifically cited, together with the need to take additionalmeasures to identify the customer.

3-1.5 Right to Financial Privacy ActThe Right to Financial Privacy Act (RFPA) requires that a financial institutionnotify its customer prior to providing any banking information requested bythe government. In certain limited instances, the RFPA requires the institutionnot to notify its customers of the government’s request. In order to challengethe government’s access to customer records, the customer must show somefactual basis supporting an allegation that the records are not being soughtfor a legitimate purpose; however, the government has the burden of proofthat it is justified in receiving the requested records.

Amendments to the RFPA contained in the Financial Institutions Reform,Recovery, and Enforcement Act of 1989 prohibit a financial institution fromnotifying any person named in a grand jury subpoena about the subpoena.The amendments also authorize the government to apply for a court order todelay the required RFPA notice to the customer under certain circumstances.



3-1.6 Federal Digital Signature LegislationNo federal legislation on digital signatures has been enacted at this time.Some of the following bills addressing digital signature issues have recentlybeen introduced in Congress and referred to committee:

� Computer Security Enhancement Act of 1997 (last action date11/20/97) — A bill to amend the National Institute of Standards andTechnology Act to enhance the ability of the National Institute ofStandards and Technology (NIST) to improve computer security and forother purposes.

� Electronic Financial Services Efficiency Act of 1997 (last action date11/24/97) — A bill to provide for the recognition of digital and otherforms of authentication as an alternative to existing paper-basedmethods; to improve the efficiency and soundness of the nation’scapital markets and the payment system; to define and harmonize thepractices, customs, and uses applicable to the conduct of electronicauthentication; and for other purposes.

� Electronic Commerce Enhancement Act of 1997 (last action date11/20/97) — A bill to enhance electronic commerce by requiringagencies to use digital signatures that are compatible with standards forsuch technology used in commerce and industry, to enable persons tosubmit federal forms electronically, and for other purposes.

� Digital Signature and Electronic Authentication Law of 1998 (last actiondate 3/31/98) — A bill to amend the Bank Protection Act of 1968 tofacilitate the use of electronic authentication techniques by financialinstitutions and for other purposes.

3-2 State Requirements and InitiativesThe following is a list of state laws and legal initiatives that could affect theoverall operation of Postal Service electronic commerce. Where possible,each discussion provides a brief description of the overall effect to the PostalService Web application.

3-2.1 Uniform Commercial Code (Article 4A)UCC Article 4A addresses wholesale wire transfers that may be completedby electronic (or wire) communications. Article 4A defines securityprocedures to be established between customers and banks that address thefollowing issues:

� Verifying that a payment order or communication amending orcanceling a payment order is that of the customer.

� Detecting errors in the transmission of the content of the payment orderor communication.

Unlike the EFTA, UCC Article 4A places substantial responsibility on thecustomer to protect the integrity of the security procedures agreed upon witha bank. The customer is strictly liable for misuse of security procedures



unless he or she can prove that the compromise of security did not originatewith the customer or his or her users or equipment. In some cases, PostalService Internet customers will be held to this legislation.

3-2.2 UCC Draft Revisions Related to ElectronicCommerceRevision proposals for the UCC are managed by committees formed by theNational Conference of Commissioners on Uniform State Laws. Someproposed revisions with potential impact on electronic commerce addressArticles 2, 2A, 2B, and 5 of the UCC. The proposed revisions would repealthe statute of fraud for sales of goods by providing that a “contract ormodification thereof is enforceable, whether or not there is a record signed bya party against whom enforcement is sought, even if the contract ormodification is not capable of performance within one year of its making.”Other revisions include the following:

� Provide for the use of the term record as a replacement for writing.

� Accommodate the use of electronic signatures where appropriatemethods of authentication are implemented.

� Provide for contract formation in the absence of direct humaninvolvement.

� Provide for attribution and authentication of electronic messages.

� Provide for the allocation of liability among originators, recipients, andintermediaries when electronic messages are involved.

Each aforementioned provision could directly affect the Postal Service Webapplication and its external participants.

3-2.3 State Digital Signature LegislationCalifornia and Utah were the first and second states, respectively, to adoptdigital signature legislation. (Other states have adopted legislation related todigital signatures, and many others are considering it.) The California DigitalSignature Act and the Utah Digital Signature Act represent two extremes oflegislation. The California act provides legal validity for electronic documentsand delegates rule-making authority to other California governmentauthorities. It only briefly describes the legality of using digital signatures. Incontrast, the more comprehensive Utah act addresses licensing andregulation of certificate authorities, the duties of certification authorities andsubscribers, and the effect of digital signatures, state services, andrepositories.

The major problem that digital signature legislation presents for the PostalService Web application is that there are no formal federal regulations. Manystates are drafting their own legislation, and this could potentially lead todifferent implementations of digital signatures based on each state’sprovisions.

4Payment Types and Methods


4 Payment Types and Methods

The current nationally available Postal Service Web site requires that allpurchase transactions be made using the telephone after the customerselects products from an electronic catalog available on the Postal ServiceWeb site. This is considered an out-of-band transaction. The Postal Servicecurrently accepts Visa, MasterCard, American Express, and Discover cardsas credit card payment options. In addition, several online pilot projectsaccept credit cards, using various back-end systems. To implement anationally rolled out in-band (online) purchasing system, the Postal Servicewill have various methods of payments from which to choose. Exhibit 4presents payment methods in three broad categories. The list does notinclude all possible payment methods available; as other payment methodsbecome relevant to the Postal Service, the list will be updated. This sectiondescribes those payment methods and includes information about what dataneed to be provided and stored by each of the parties. In addition, if apayment method requires security measures beyond the baselinerequirements of this handbook, those particular security measures areoutlined.

Note: When the role of merchant is described in purchase transactions inSection 4, it always refers to the Postal Service.

Exhibit 4Payment Categories and Methods

Category Methods

Demand Deposit BankingMethods

� Lockbox (checks or money orders) – Section 4.1

� ACH Debit – Section 4.2� ACH Credit – Section 4.3� Fedwire – Section 4.4

Card Methods � Online Debit – Section 4.5� Off-line Debit – Section 4.6� Credit Card – Section 4.7

New Technologies(under investigation)

� SET-Enabled Credit Card – Section 4.8� Postal Service Stored Value Account

(PEPP Cache) – Section 4.9� Digital Cash (CyberCash) – Section 4.10� FSTC E-Check – Section 4.11� BIPS – Section 4.12



4-1 LockboxThe lockbox allows customers to add funds to an account out-of-band, butuses the account to make payments in-band. The Postal Service CorporateTreasury discourages the use of lockboxes for any type of payment forInternet usage because payment for electronic commerce applications shouldbe through electronic mechanisms. The traditional lockbox model is set up forcustomers to make monetary deposits to a lockbox (either a bank’s physicallockbox or a mail-in post office box) by way of check, money order, or cashpayments. The bank then removes the payments from the envelope anddeposits the money into an account set up for the merchant (Postal Service)or the merchant’s product. The Postal Service currently uses the traditionallockbox to accept payment for the Computerized Meter-Resetting System(CMRS), among other applications. The lockbox payment method could beused to load a customer’s Postal Service online account that could then beused to pay for Postal Service goods and services. Lockbox services areprovided to the Postal Service by Citibank; electronic lockboxes will beprovided by the vendor that is awarded the Postal Electronic PaymentPlatform (PEPP) contract and will have to be consistent with PEPPregulations.

4-1.1 Transaction DescriptionExhibit 4-1.1a illustrates a basic lockbox transaction. A Postal Servicecustomer or service subscriber makes a deposit to the lockbox by way of acheck or money order, using the mail or a delivery service. When the lockboxbank operator receives the payment, it credits the payment to an account.The information from the payment envelope (payment and coupon relevant tothe transaction) is used to credit the merchant (Postal Service) bank account.Once the check is deposited, the Postal Service must either deliver theservices or goods ordered or credit an online account that is used by thecustomer to spend down the amount through an online account. Details forthe out-of-band lockbox transactions are in Exhibit 4-1.1b. The in-bandtransactions are described in Section 4-9.

4-1.1.1Payment Types and Methods


Exhibit 4-1.1aLockbox Transaction

Processmail andcreatebatch

Capturedatafromcouponsandchecks

Clearchecks:encodeanddeposit

Sendremittancedata toclient andcompletesystemmaintenance

Mail is openedby automatedmachines.

Operatorcreatesbatches bylockboxnumber forprocessing.

Coupons andchecks areprocessed ontransports.

System readscheck MICR andcoupon OCRand createsimage.

Systemreconcilespaymentsreceived.

Operator sendsencoded checksto checkprocessing.

Operator transmitsremittance data toclients via file transfer.

System managersends activity datato analysis systemfor billing.

Source: Tower Group

�

�

�

�

�

�

�

�

Exhibit 4-1.1bLockbox Out-of-Band Transactions

To Postal To Customer To Processor

From Postal � Data from financial institution must be stored in account database accessible

by way of Internet

� Destination address of lockbox� Account number or remittance total coupon

� Account number information for customer

From Customer � Check or money order� Account number or remittance data on coupon

From Processor � File of payments received� File of payments cleared

4-1.1.1 Customer Requirements for Use

The customer must have the address of the lockbox remittance processorand the customer’s Postal Service account number (see Exhibit 4-1.1b). Thecustomer may use his or her checking account or money orders.



4-1.1.2 Postal Service Requirement for Use

Currently, Citibank provides the Postal Service’s lockbox service. In thefuture, electronic lockbox services will be provided under PEPP. Any PostalService product or service developer must adapt its Web application toinclude payments (made by way of lockbox) to the Postal Service account.The Postal Service must provide customers with payment coupons to ensurethat the customers have the appropriate bank account numbers along withthe checks or money orders they send. On the back end, the Postal Servicemust set up accounting structures to ensure that customers’ payments tolockbox operators are good when deposited and, like checks at the retail unit,are available for customers to purchase goods and services immediatelyupon deposit. The Postal Service must develop policies to deal withsituations in which there is a case of not-sufficient funds (NSFs).

4-1.1.3 Funds Availability

Funds are available when the customer’s payment (check or money order) isdeposited and the financial institution notifies the merchant (Postal Service).Generally, this is the working day after the payment is retrieved from thelockbox. Funds are not guaranteed until they are cleared through the FederalReserve System, that is generally two to four days after the checks aredeposited.

4-1.1.4 Cost to the Postal Service

Actual cost to the Postal Service depends on the contract that it has with themerchant lockbox operator. The industry average to process a lockboxtransaction is between 20 and 40 cents.

4-1.2 Suitability for Postal Service Use as an InternetPayment MethodBy their nature, paper lockbox operations are not well suited for online,immediate transactions. Customers who send checks or money orders to apaper lockbox must wait until the mail is opened and the checks aredeposited and cleared before the customers have access to their funds.While this process works well for predictable transactions, it does not work forInternet real-time transactions.

Electronic lockbox transactions, in which a customer sends a Fedwire orinitiates an ACH credit to a lockbox, are more appropriate for Internettransactions because they are electronic forms of payment.

If the Postal Service establishes PEPP Cache for customers to use withInternet-accessible applications (see Section 4-9), the lockbox (either paperor electronic) could be used as one method for the customer to fill (or addvalue to) that account. The Postal Service and many of its customers arefamiliar with lockbox operations; Postal Service accounting has establishedreporting requirements and methods for dealing with lockbox remittanceinformation and payment.

4-1.5Payment Types and Methods


One issue that arises with lockbox operations over the Internet is the speedwith which the Postal Service makes funds available for customers to use. Assoon as checks are deposited, lockbox operators provide remittanceinformation to the Postal Service; however, these funds are not guaranteeduntil the check clears all the way through the Federal Reserve System. It ispossible that a notice of NSF will be returned from the customer’s depositorybank as many as several days after the check is deposited. If the PostalService uses the lockbox method of adding value to accounts, it should beaware of the risk of NSFs and develop a policy for dealing with such cases.Electronic lockbox operations avoid this risk because, using either ACH creditor Fedwire, the funds are guaranteed when they are received by theremittance processor (see Sections 4-3 and 4-4).

4-1.3 Authentication and AuthorizationAuthentication of the customer is handled by the customer’s issuing bank byway of the check-clearing process. Unless the customer or bank reports thatthe customer did not write and sign a particular check (check fraud), thecustomer is assumed to be authenticated.

Authorization, which in this case means that the customer has fundsavailable on which to write a check, occurs through the check-clearingprocess. When the merchant’s lockbox deposits a check, the deposited checkis routed either through the Federal Reserve System (from the Fed office inthe presenting district to the Fed office in the paying district) or through anACH. The paying bank then sends information back through the Fed or theACH to confirm that the customer had sufficient funds to pay the amount onthe check. At this point, the check is authorized.

4-1.4 Settlement DescriptionAfter the merchant’s lockbox receives notice that the funds are authorized orguaranteed, the merchant’s lockbox sends payment through the ACH to themerchant’s bank. The merchant’s lockbox has settled and cleared thetransaction when it receives payment for the check in the daily net settlementthat occurs through the ACH and Fed network.

4-1.5 Additional SecurityNo additional security is required for the Postal Service to allow a customer touse a lockbox to send payment to refill a Postal Service account. If thecustomer requests an account online, the additional security would apply(see Section 4-9).



4-2 Automated Clearinghouse Debit

4-2.1 Transaction DescriptionThe ACH debit is one of several methods that allow customers to fill thePostal Service PEPP Cache out-of-band, but use PEPP Cache in-band (seeSection 4-9). The customer provides the Postal Service with authorization todebit the customer’s demand deposit account (DDA, i.e., checking account),which is held at the customer’s bank. The Postal Service can work withcustomers to determine whether to debit a set amount from the customer’sDDA account each month or establish a system whereby the customerinforms the Postal Service how much the customer would like to havedebited. Exhibit 4-2.1a describes the data flow for the out-of-bandtransaction, and Exhibit 4-2.1b illustrates an ACH debit transaction.

The Postal Service must work with a financial institution to originate the ACHdebits; ACH debit services will be provided for the Postal Service by thevendor selected under the PEPP RFP. The Postal Service may considerallowing a customer who has filed the required physical signature to pay for agood or service by requesting the Postal Service to initiate a debit against thecustomer’s demand deposit account (DDA) when the customer goes throughthe checkout phase.


The customer must provide a one-time written authorization to the paymentreceiver (the Postal Service) providing authorization for the receiver (payee)to debit the customer’s demand deposit account at the customer’s ownfinancial institution. The written authorization must include a signature andthe customer’s appropriate routing and transit information, including theaccount number. Currently, ACH rules do not allow the customer to initiate anACH debit online without a preexisting written authorization with a physicalsignature. The Postal Service could choose to make the form to authorize anaccount debit available on a Postal Service Internet site. However, thecustomer must still print the form and send it to the Postal Service with aphysical signature.



Exhibit 4-2.1aACH Debit Payment Model

Customer

5. Statement

Customer FinancialInstitution (RDFI)

Merchant FinancialInstitution (ODFI)

2. ACHOriginationFile

Merchant

4. Funds

3. Originates ACH Transaction

1. One-Time Authorization

6. Confirmation of funds

Source: NACHA

Exhibit 4-2.1bACH Debit Out-of-Band Transaction

To Postal To Customer To ODFI To RDFI

FromPostal

� Monitor and credit incoming ACH payment to correct account

� Notification of ACH debit from Internet database� Written authorization from customer

FromCustomer

� Written authorization to debit DDA (DDA account information)

� Out-of-band; must maintain open account

FromODFI

� Nightly reports of incoming ACH debit� Notification of

exceptions or NSF

� Prenotification of ACH debit to ensure that customer provided correct account information� Notification of

ACH debit

FromRDFI

� Notification of NSFs� Notification of ACH debit

� ACH debit funds sent� ACH debit funds cleared



4-2.1.2 Postal Service Requirements for Use

After the customer provides written authorization to the Postal Service, thePostal Service can originate an ACH debit to the customer’s financialinstitution. The Postal Service, through its relationship with a creditor ororiginating depository financial institution (ODFI), initiates a request for anACH debit. The request is sent through an automated clearinghouse to thereceiving depository financial institution (RDFI), the customer’s depositoryfinancial institution. The RDFI processes the request and sends the moneyback, through an ACH or the Fed, to the ODFI. The Postal Service must havethe customer’s authorization on file with a physical signature. The PostalService must also have the customer’s bank account information. The PostalService relationship with its ODFI must allow for the notification that an ACHdebit has been originated, when the funds have been credited to a PostalService account, and when the funds are guaranteed to ensure properdelivery of goods or services.


Funds are generally available within two business days after the ACH debit isoriginated. ACH payments are value-dated. Rather than settling immediately,or at the end of each day, each ACH payment is entered with a value datethat specifies the day on which it will be settled. ACH payments aretransmitted to the Federal Reserve System within two days of the value date.


Depending on the Postal Service’s relationship with a bank, the cost of anACH debit can be significantly lower than lockbox operations. Industryaverages for an ACH debit range from 3.5 to 7.5 cents, according to theNational Automated Clearinghouse Association (NACHA).

4-2.2 Suitability for Postal Service Use as an InternetPayment MethodThe ACH debit payment methodology introduces cash liability risks to thePostal Service because the Postal Service does not know if there aresufficient funds in the customer’s account until the ACH debit is processed.The Postal Service could risk revenue if it allowed customers to use ACHdebit to pay for a received good on day zero when the Postal Service doesnot know whether the customer has sufficient funds until day 2 or later. Thisrisk is similar to the risk that the Postal Service faces in accepting a check atthe retail unit. Using ACH debit as a method for establishing and maintaininga Postal Service PEPP Cache has less risk. However, for customerconvenience, Postal Service product managers might consider allowingcustomers who have signatures on file to pay for a good or service using theACH debit mechanism.



NACHA is currently piloting an Internet payment system that would notrequire signatures on file and that would use the Internet to perform ACHtransactions between customers and ODFIs. This pilot uses public keycryptography for transactions to do the following:

� Encrypt and decrypt transaction data.

� Create digital signatures that validate each party in a transaction.

� Ensure the integrity of data in a transaction.

� Create, revoke, and validate digital certificates used by all parties in thetransaction.

� Decrypt and validate all transaction messages from participants.

NACHA has chosen four banks to participate in this test. In the test,customers will apply for a digital certificate, transmit the certificate over theInternet to secure online purchases, and debit their accounts by way of theACH network. If this pilot is successful, the Postal Service could considerusing ACH debit for real-time payment online.

4-2.3 Authentication and AuthorizationThe customer is authenticated and the account transaction authorizedthrough the written authorization form that the customer signs (out-of-band)to authorize the transaction. If the Postal Service uses ACH debit forreal-time payments, some additional method of authenticating the customer(i.e., user name and password or digital signature) should be instituted toensure that the customer whose signature is on file is the one requesting theinitiation of the ACH debit. The customer can also authorize monthlyreloading of his or her account or allow the Postal Service to reload when thebalance goes below a designated amount.

4-2.4 Settlement DescriptionThe ACH debit does not settle until the funds have been cleared through theregional ACH or the Federal Reserve System. The ODFI may receive noticeof funds availability, but funds are not guaranteed until after the settlementprocess has occurred. At that point, the Postal Service is notified by the ODFIwhich ACH debits have cleared. The Postal Service can either allow thecustomer to use the funds upon first notification of funds availability or canwait until funds are guaranteed before allowing the customer to spendagainst his or her Postal Service account. In the scenario of real-time ACHpayment, customers would receive goods and services immediately uponauthorizing the Postal Service to initiate an ACH debit.

The Postal Service must be aware that under Regulation E of the ElectronicFunds Transfer Act, users of EFT have up to 60 days to revoke an ACHpayment they believe to be either fraudulent or in error. This rescind clausemay add additional risk to allowing users to pay using ACH debit (althoughusers wishing to rescind payment must submit a written affidavit explainingwhy they wish to rescind the payment).



4-2.5 Additional SecurityNo additional security is required for the Postal Service to allow a customer touse ACH debit to pay to refill a Postal Service account. If the customerrequests an account online, the additional security described in Section 4-9on Postal Service accounts would be required.

If the customer is allowed to request an initiation of an ACH debit to pay for agood or service in real time, security must be provided to authenticate theuser to prevent fraudulent use of the ACH debit process. Authentication forhigh-value transactions should require digital signatures. For lower-valuetransactions, a randomly assigned user name and password (sent to thecustomer through e-mail) would be sufficient.

4-3 ACH Credit

4-3.1 Transaction DescriptionACH credit is used for direct deposit of payroll checks. Currently, noimplementation exists in which ACH credit could be used for transactions onthe Web. ACH credit requires the payment originator to have a directrelationship with a bank that sends transactions out on behalf of theoriginator. Exhibit 4-3.1a illustrates the ACH credit model, and Exhibit 4-3.1blists the transaction data flows. Generally, banks will not issue ACH credit forcustomers on an ad hoc basis. Instead, the ODFI has an ongoing relationshipwith a business customer that allows the customer to send a file (generallyfor payroll disbursements) to the bank to send disbursements out to apredetermined list of accounts across numerous RDFIs. Essentially, banksare not set up to allow customers to initiate ACH credits on an ad hoc basis.

It is possible that a customer could use ACH credit for a monthly fixed-dollartransaction sent to the merchant on a scheduled basis. If a bank were toallow a customer to use ACH credit to load Postal Service PEPP Cache, thePostal Service could use the vendor selected through the PEPP procurementprocess as the RDFI.



Exhibit 4-3.1aACH Credit Payment Model

Customer

4. Statement

Customer FinancialInstitution (ODFI)

Merchant FinancialInstitution (RDFI)

Source: NACHA

Merchant

3. Funds

2. Payment information

1. One-time authorization, routing, and transit information

3. ACH transaction origination

Exhibit 4-3.1bACH Credit Out-of-Band Transactions

To Postal To CustomerTo Customer’s FinancialInstitution (ODFI)

From Postal � Monitor and credit incoming ACH payment to correct Postal Service customer account

� Bank transit and routing information� Account number

From Customer � Payment instructions� Payment schedule� Agreement for payment

From Customer’sFinancial Institution(ODFI)

� Payment� Information about accounts to which to apply payment

� Ability to track payment� Report of payment made



4-3.1.1 Customer Requirement for Use

To initiate a direct deposit, the customer must have a formal agreement witha financial institution to originate ACH transactions. The agreement mustinclude a provision that the customer and the financial institution agree toabide by NACHA rules and should include processing schedules, provisionsrelated to the security requirements of the Uniform Commercial Code (UCC),and details pertaining to services and charges. The customer must alsoobtain authorization from the merchant, either oral or written, to send an ACHcredit. Finally, the customer needs to obtain appropriate routing and transitinformation for the merchant’s financial institution and an accurate accountnumber for the merchant at that institution. (The Postal Service could providethis information to customers on its Web site.)

Once the agreement has been established, the customer must transmitpayment information to the customer’s financial institution according to theprocedures detailed in the agreement with the financial institution. If thecustomer has an account with the same bank as the merchant, the financialinstitution will credit the account in that institution. All other transactions areforwarded to an ACH operator and into the ACH network.

The ACH operator sorts the records and immediately distributes them to theappropriate financial institution of the merchant. According to ACH rules,funds must be distributed to the merchant’s account at the opening of thebusiness day on which the delivery was scheduled.


The merchant (Postal Service) would be required to set up an account intowhich the ACH credits could be deposited. The Postal Service would need toprovide the customer with its financial institution’s routing and transitinformation, as well as the account number into which it wanted fundsdeposited.

The Postal Service would need to work with the ACH network to determinethe accompanying Postal Service specific information that would travel withthe ACH credit to accurately credit payment to a customer-held PostalService account.


Funds are available on the morning of the business day on which they arescheduled to be delivered.


There is no cost to the Postal Service for accepting ACH credits. Thecustomer will pay a fee to initiate this type of payment.



4-3.2 Suitability for Postal Service Use as an InternetPayment MethodToday, ACH credit is not suitable for use by the Postal Service because few, ifany, financial institutions allow customers to make ad hoc payments usingACH credit.

The Payment Systems Interface Work Group of the Internet Council of theNational Automated Clearinghouse Association has developed a Credit PushInternet Payment Model that could be used for both corporate and customerpayments on the Internet using an ACH credit.

The Credit Push Internet Payment Model (see Exhibit 4-3.2) requires theorigination of an ACH credit payment from a customer’s financial institution toa merchant’s financial institution pursuant to payment instructions transmittedfrom the customer to its financial institution. The initiation of paymentinstructions is predicated on the following:

� Both the customer and merchant having been issued digital certificatesfrom their respective financial institutions.

� Certificate authorities (CAs).

� A purchase decision being made by the customer while at themerchant’s Web site.

� The authentication of the merchant’s certificate by the customer’sfinancial institution’s CA.

The following steps describe the payment and certificate flows in the CreditPush Internet Payment Model:

1. Customer and merchant are issued certificates by their respective CAsof their financial institution.

2. Customer visits merchant’s Web site and makes purchase decision(purchase order).

3. Customer captures merchant’s bank and account information(encrypted) and digitally signed invoice.

4. Customer transmits signed invoice, his or her certificate (optional: bankmay elect to use alternative or existing security mechanisms), andmerchant’s certificate to the customer’s bank (authorizing paymentdependent upon authentication of merchant’s certificate).

5. Interbank certificate validation or authentication occurs.

6. Customer’s financial institution originates ACH credit and paymentguarantee for merchant.

7. Merchant authorizes shipment of goods to customer.

8. Merchant’s financial institution receives and posts ACH credit tomerchant’s account.

9. Merchant’s financial institution transmits remittance information tomerchant.



Exhibit 4-3.2NACHA Credit Push Internet Payment Model

7. Sends goods.

Source: NACHA Internet Payment Council

2. Places order.

3. Sends digitally signed invoice & merchant’s

certificate.

Customer’s FinancialInstitution

Merchant’s FinancialInstitution

Customer

5. Bank validates merchant’s certificate with merchant’s bank.

1. Bank issues customer

certificate.

6. Originates payment.

8. Receives & posts credit.

9. Transmits remittance information.

1. Issues merchant

certificate.

Internet transaction

ACH Network

4. Sends signed invoice,

merchant’s certificate, &

own certificate to bank.

Merchant

The Internet Council of NACHA is sponsoring the Credit Push Pilot Test,currently in its second phase, the test of the certificate authority (CA)interoperability. Citibank, Mellon Bank, and Bank of America are the financialinstitutions participating in the test, as well as several digital certificatesoftware vendors, including Entrust and VeriSign. (The Postal Service couldchoose to become part of the test for this new payment model.)

The overall goal of the pilot is to conceptually prove the viability of digitalcertificates for Internet commerce in an environment in which financialinstitutions, acting as the CAs, issue, exchange, and honor certificates onbehalf of their customers.

4-3.3 Authentication and AuthorizationA prenotification can be used by the customer’s bank to ensure that the bankhas the correct bank routing and account information for the customer. Thiscan be used as a form of authentication. Because the customer initiates thetransaction, there is no need for the merchant (Postal Service) to receive anauthorization. The ACH credit is considered notice of payment.



4-3.4 Settlement DescriptionACH credit transactions are settled in batch at the end of day when they areinitiated. The customer’s account is debited before the ACH payment is madeto the merchant’s account. In the case of ACH credit, the customer is notifiedthat the funds have been sent, time-certain, to his or her account, and thefunds are guaranteed and available to be used on the morning of the first daythey are available.

4-3.5 Additional SecurityNo additional security is required for an ACH credit in the traditional model. Ifthe Postal Service decided to join in the Credit Push Pilot Test, both thePostal Service and its customers would be required to have digital certificatesthat could be accepted by the participating financial institutions.

4-4 Fedwire

4-4.1 Transaction DescriptionFedwire is one of several methods that allow customers to replenish anaccount out-of-band, but use the account in-band. Fedwire is an electronictransfer system developed and maintained for use by the Federal ReserveSystem and is generally used for large dollar transactions. It enables financialinstitutions to transfer funds and book-entry securities finally and irrevocablynationally and even internationally through system extensions. A majorbenefit of the Fedwire system is that in addition to the property ofirrevocability, it provides for immediate finality of payment. This feature setsFedwire apart from any other electronic payment system operating in theUnited States today.

Fedwire was designed to provide a system for the transmission of large,time-sensitive payments and is used extensively by the Unites StatesTreasury and other federal agencies for the collection and disbursement offunds. This system is also used to provide a net settlement system amongthe Federal Reserve System’s 11,600 member depository institutions.

A typical payment processed through the Fedwire system is shown in Exhibit4-4.1a. The settlement for this type of payment is also detailed in the diagramand is accomplished through the book-entry settlement system that isimplemented within the Federal Reserve System and member banks.Although settlement is only completed at the end of the Fedwire business dayand is accomplished as a net settlement, the Federal Reserve Systemguarantees all payments processed through the Fedwire system, providedthat the payment is accepted, processed, and completed. Transfers throughthe Fedwire system are regulated by a number of Federal Reserve Systemregulations and guidelines. Fedwire in-band and out-of-band transactions areillustrated in Exhibits 4-4.1b and 4-4.1c.



Exhibit 4-4.1aFedwire Transaction Payment Model

1. Requests $1Min its depositoryaccount at customer’s

financial institution be transferred to merchant’s account located at another depository institution.

Bank ADebit$1MCredit

Bank BDebitCredit$1M

Bank A Bank B

Debit

$1M

Credit Debit

$1M

Credit

Customer Merchant

Federal Reserve System


Merchant’s FinancialInstitution2. Transfer $1M for

customer by sending a message over Fedwire

authorizing the Federal Reserve to electronically debit customer’s account at the Reserve Bank for $1M and to transfer the $1M to merchant’s account.

3. Once the Fedwire transaction is completed, merchant’s financial institution makes the designated $1M payable and available to merchant on the day that payment occurs.

4. Once the payment of $1M credited to merchant’s financial institution account, the Fedwire funds transfer

is completed. For most funds transfers involving online depository institutions, the time that elapses between when a

funds transfer message is sent and when a payment

is received is a matter of seconds.

Exhibit 4-4.1bFedwire In-Band Transactions


From Postal � Amount of funding for account

� Routing transit number (ABA number)� Postal destination bank account number� Beneficiary name� Dollar amount

From Customer � Federal reference number� Dollar amount of payment

From Processor



Exhibit 4-4.1cFedwire Out-of-Band Transactions


From Postal � Advice of payment received� Advice of federal reference number

From Customer � Routing transit number (ABA number)� Postal destination bank account number� Beneficiary name� Source account number� Dollar amount

From Processor � Advice of receipt of funds with federal reference number

� Advice of receipt of instruction� Advice of payment completion with federal reference number


The Postal Service must also maintain an account with a depositoryinstitution that can exchange Fedwire transmissions. The Postal Service musthave the back-end accounting system in place to send information aboutfunds received by way of Fedwire to a customer’s PEPP Cache account sothat the customer can access his or her account through the Internet.


Through Fedwire, funds would typically be available in a Postal account onthe same day that the customer initiates the transaction. The FederalReserve System processes payments from 12:30 a.m. Eastern time (ET)through 6:30 p.m. ET each business day, with no business transacted onmajor bank holidays.

Payment requests submitted outside of the Federal Reserve Systemprocessing window are held by the originating depository financial institutionuntil the next business day and are then processed normally.


The processing costs of a Fedwire transaction vary based oncustomer-negotiated criteria and originating institution policy. The FederalReserve System currently imposes a minimum fee of 45 cents pertransaction upon both the originator and receiver of a Fedwire. This cost maybe in addition to any fees imposed by the originating and/or receiving bankinginstitutions. The actual costs of this type of payment instrument will dependupon the rate structure negotiated by the Postal Service with its serviceinstitutions.



4-4.2 Suitability for Postal Service Use as an InternetPayment MethodThe Fedwire payment mechanism may be suitable for use by major mailersand other large customers to make deposits into Postal Service accounts thatcould then be used to conduct transactions over the Internet.

Fedwire is not currently implemented to allow the initiation of paymentsdirectly for online transactions and is therefore not suitable for use by anaverage customer, primarily because of the cost implications of processingtransactions through this system. Fedwire is intended for the settlement oflarge dollar value transactions (i.e., $1,000 or more).

4-4.3 Authentication and AuthorizationThe origination and processing of this type of payment instrument is carriedout beyond the control of the Postal Service; therefore, most authorizationand authentication mechanisms will be determined and administered by thecustomer’s banking institution. (If the Postal Service began using this systemfor outbound payments, this issue would need to be reexamined.)

The Postal Service should require that customers complete a registrationprocess in order to facilitate account reconciliation. Specifically, thisregistration process would allow the Postal Service to set up depositaccounts or subaccounts for its customers into which payment can bedirected. Such a mechanism would allow customers to transfer funds intotheir accounts without first notifying the Postal Service of the impendingtransfer.

4-4.4 Settlement DescriptionAll Fedwire transfers are completed on the day that they are initiated,generally in a matter of minutes, assuming that the transaction has beenprocessed during a normal Federal Reserve System processing window.These transactions are guaranteed to be final by the Federal ReserveSystem as soon as the receiving institution is notified of credit to its account.

4-4.5 Additional SecurityBecause the origination and processing of this type of payment instrumentare carried out beyond the control of the Postal Service, any securitymechanisms surrounding this type of payment would likely be administeredby the originating and receiving financial institutions.

The Postal Service should take extreme care in protecting any customeraccount information contained in messages received from the customers’financial institutions. For example, if the originating account number isprovided to the Postal Service in the confirmation received from the PostalService’s bank, it is imperative that this information be treated in the samemanner as a credit card number. A number of steps can be taken to ensurethe confidentiality of this information, but an ideal solution would be toselectively block certain characters of this field (for example, only every third



character could be stored in the database). The storage of this information isnot critical to any audit path for this type of payment because the FederalReserve System reference number has been included. With this identifier, itshould be possible to trace this payment through the Postal Service’s bankinginstitutions without undue difficulty.

4-5 Debit — OnlineThere are two forms of debit cards. Online debit uses the processing systemsand switch networks established for the automated teller machine (ATM)industry. Off-line debit (discussed in Section 4-6) uses the acquiring, cardassociation, and processing network of the credit card industry. Debit cardtransactions draw funds directly out of the customer’s deposit account (i.e.,checking or savings).

4-5.1 Transaction DescriptionOnline debit uses the infrastructure developed for the ATM industry in the1980s (see Exhibit 4-5.1a). In an Internet online debit transaction, thecustomer chooses to pay for the purchase of goods or services with his orher debit or ATM card. The customer is required to provide the debit cardnumber (not the customer’s account number, but rather another assignednumber), provide the debit card expiration date (if the card has one), andenter a PIN (personal identification number) into a secure PIN pad attachedto his or her computer. The PIN is used in place of a signature to authenticatethe customer to the issuing bank or processor. The customer submits thisinformation to the merchant (Postal Service).



Exhibit 4-5.1aOnline Debit Payment Model

4. Settlement at end of day via ACH.

USPS Customer(ATM Cardholder)

with PIN PadUSPS (Merchant)

Acquiring Processor


Customer’s FinancialInstitution (Issuer)

Issuer Processor

Internet

Switch Networks

3. Order/payment confirmed.

1. Order placed.

2. Payment authorization request/

response.

4. End-of-daysettlement ofmoney owedto merchant.

4. End-of-daysettlement ofmoney owedto merchant

bank.

2. 2.

RegionalSwitch

RegionalSwitch

NationalSwitch

Source: Tower

Routes authorization request andtransaction information betweenacquiring and issuing processors.

Online debit card data flows are considered out-of-band and are listed inExhibit 4-5.1b. The merchant forwards the information (debit card number,PIN, and transaction amount) to its acquiring processor. The acquiringprocessor, in turn, sends the transaction information through the ATM switchnetwork to the issuer (or the issuer’s processor) to get authorization for thetransaction. The ATM switch network is responsible for switching transactionauthorization messages between the acquiring processor’s and the issuingprocessor’s systems. Switches also determine the net settlement betweenbanks at the end of each day. The issuing processor performs cardholder andaccount authentication and transaction authorization. Once authorization hasbeen received by the acquiring processor and sent back to the merchant, themerchant can authorize the transaction and fill the customer’s order.



Exhibit 4-5.1bOnline Debit Card In-Band Transactions


FromPostal

� Transaction data storage� Reporting� Reconciliation� Accounting information

� Success or failure of transaction� Transaction ID or order number

� Encrypted PIN� Transaction information (amount)� Debit card number

FromCustomer

� Encrypted PIN� Debit card number

FromProcessor

� Authorization� End-of-day settlement amount


Online debit requires the customer to have both an ATM or debit card and asecure PIN pad (attached to his or her computer). The secure PIN padenables the customer to enter the PIN securely and to encrypt it in a way thatthe merchant and the merchant’s acquiring processor can interpret it.


The Postal Service must ensure that the payment server or platform that ituses can receive the encrypted PIN and transfer it to the acquiring processor.Alternatively, if the Postal Service chooses to accept debit cards with PINssent unencrypted but within the SSL envelope (not recommended), its serverwill need hardware and software to encrypt the PINs to be sent to theacquiring processor, using the encryption method that the processor expects.


Settlement occurs between the issuing bank or processor and the merchantbank at the end of the day. The issuing processor reports to the issuing bankon money owed to the merchant bank. The issuing bank transfers money tothe merchant bank by way of the ACH network. The acquiring processor thenreports to the merchant bank what is owed to the merchant bank forreconciliation and reporting.

Based on the Postal Service’s relationship with its acquiring processor, fundsare generally available the next business day.




Online debit fees are low to the issuing bank and are set by the ATM switchnetwork providers. Generally, they are transaction-based. The Postal Servicewould be responsible for paying an interchange fee, half of the switch fee,and the processing fee. The industry average for these fees is between 11and 30 cents per transaction.

4-5.2 Suitability for Postal Service Use as an InternetPayment MethodOnline debit provides a benefit to the Postal Service in that the customer’saccount is debited as the transaction occurs. This means that there is no riskof NSF.

Note: Current EFT network rules do not guarantee payment for PIN-lesspayments.

The use of the PIN also provides stronger authentication of the cardholderthan the use of billing address information for verification; however, requiringthe customer to have a PIN pad may be considered unduly burdensome tothe customer. PIN pads that attach to PCs range in price from $150 to $250.Without a PIN pad at the customer’s PC, the Postal Service and the customertake on risk. For the customer, passing the PIN unencrypted may allow aperson in the middle to intercept his or her debit card number and PIN anduse his or her debit account immediately. Passing the PIN encrypted andusing an SSL provides the customer greater protection, but puts the burdenon the Postal Service to decrypt the PIN from the secure session and toreencrypt it to be sent through the acquiring processor to the issuingprocessor (where it is finally verified).

In Phase II of the NACHA Internet Council’s Certificate AuthorityInteroperability Pilot, the STAR Point of Sale (POS) network has proposed totest using digital certificates, in place of PINS, to authenticate customers whowant to use their online debit card for Internet transactions. In this scenario,the issuing bank would authenticate the customer with the digital certificate,and the customer’s checking account would be immediately debited. Themerchant would receive the approval or denial of the purchase in real timeand then could notify the customer that the purchase was confirmed and thedelivery of merchandise is scheduled. The payment would work as follows(see Exhibit 4-5.2):

1. The customer goes to his or her bank and applies for a digitalcertificate. The bank issues the customer a certificate. (The certificateshould also include the ATM card number.)

2. The customer then goes to the merchant’s Web site and decides togive the merchant authorization to debit his or her account for productsor services. The merchant sends the customer an electronicauthorization form, which the customer digitally signs and returns to themerchant with his or her digital certificate. The customer will need toenter his or her ATM card number on the authorization form.



3. The merchant sends the customer’s certificate to the merchant’s bankfor authentication.

4. The merchant’s bank authenticates the customer’s certificate andverifies the certificate status by communicating with the customer’sbank online.

5. The merchant’s bank then notifies the merchant of the status of thecustomer’s certificate.

6. If the merchant receives a valid status on the customer’s certificate, themerchant (or the merchant’s bank or EFT processor) can then generatean online transaction to debit the customer’s card account. Within threeseconds (the average POS response time), the merchant will receivean approval or a denial.

7. The merchant can immediately proceed to ship the merchandise and toconfirm the purchase and scheduled delivery with the customer.

8. The EFT network submits funds settlement to all endpoints (banks andmerchants) by way of the ACH within hours after its 3:00 p.m. Pacifictime (PT) cutoff.

Exhibit 4-5.2NACHA Certificate Authority Pilot Payment Model

Source: NACHA Internet Payment Council

Customer

1

Merchant



EFTNetwork

ACH

6 6

653

2

7

48

88

4-5.3 Authentication and AuthorizationThe issuing bank authenticates the customer based on the card number andPIN. The issuing bank or issuing bank processor then authorizes thetransaction if there are sufficient funds in the customer’s account.



4-5.4 Settlement DescriptionSettlement occurs between the issuing bank or processor and the merchantbank at the end of the day. The issuing processor reports to the issuing bankon money owed to the merchant bank. The issuing bank transfers money tothe merchant bank by way of the ACH network. The acquiring processor thenreports to the merchant bank what is owed to the merchant bank forreconciliation and reporting.

4-5.5 Additional SecurityThe National Automated Clearinghouse Association Internet Council issponsoring a pilot in which debit cards will be issued by banks with digitalcertificates. The digital certificates will be used to authenticate the debit carduser on the Internet to the debit card issuer. Both the cardholder and thebank would need to be issued digital certificates (that could becross-certified) from their respective banks. Until an inexpensive, convenient,and secure method of submitting the PIN over the Internet is developed, thePostal Service should not accept online debit payments.

4-6 Debit — Off-line

4-6.1 Transaction DescriptionOff-line debit uses the acquiring networks and processing infrastructuredeveloped for the credit card industry. In an Internet off-line debit transaction,the customer chooses to pay for the purchase of goods or services with adebit card or check-cashing card. The transaction is essentially the same asa credit card transaction (see Exhibit 4-6.1a). The customer provides the cardnumber and expiration date.

The merchant does not know that the card is not a credit card. The merchantforwards the information (account number, expiration date, and transactionamount) to its acquiring processor and requests authorization. The acquiringprocessor processes the off-line debit transaction as if it were a credit cardand submits it to a card association network, requesting address verificationaccording to the merchant’s business rules.



Exhibit 4.6.1aOff-line Debit Payments Model

Issuing Bank(custome r’s)

1.Debit card number and PIN (submitted during SSL encrypted session).

AcquiringBank/Processor

USPS Customer Merchant

Internet

Credit CardNetworks

3.Transaction confirmation.

2.Authorizationrequest/response.

4.Statement


The card association routes the off-line debit request to the issuingprocessor. The issuing bank’s processor maintains a file with the customer’soutstanding charge amounts and limits for the off-line card. Banks generallyset the limit for off-line debit cards between $500 and $1,000. The transactionrequest is authorized if it is within this limit. The processor returns theauthorization through the card association to the acquiring processor. Onceauthorization has been received by the acquiring processor and sent back tothe merchant, the merchant can authorize the transaction and fill thecustomer’s order. Exhibit 4-6.1b lists the off-line debit card data flows.

Address verification services for off-line debit varies by the issuer. Someissuing banks make available customer address information, while others donot. If no address verification is available, Postal Service business rules arefollowed and the transaction is accepted or rejected based on these businessrules (see Exhibit 4-7.3, Address Verification System Matrix).

Off-line transaction authorization is independent from the actual balance inthe cardholder’s account; the issuing bank extends short-term credit to thecustomer. The processing system of most issuing banks issues a temporaryhold on the cardholder’s account for the amount of the purchase directly afterauthorization.



Exhibit 4-6.1bOff-line Debit In-Band Transactions


FromPostal

� Transaction data storage� Reporting� Reconciliation� Accounting information

� Success or failure of transaction� Transaction ID or order number

� Transaction information (amount)� Debit card number

FromCustomer

� Debit card number� Address information

FromProcessor

� Authorization� End-of-day settlement amount


Off-line debit requires the customer to have a debit or check-cashing card.Customers must also have a Web browser that supports SSL. The customermust still provide address information because some issuing banks supportaddress verification on off-line debit.


The Postal Service currently has a relationship with an acquiring processor.Off-line debit transactions are processed in the same way that the PostalService handles credit card transactions (see Section 4-7).

Because off-line debit does not necessarily support the Postal ServiceAddress Verification System (AVS), the Postal Service needs to determinewhether it requires a different form (i.e., digital certificates) of authenticationto be able to accept off-line debit.


Like a credit card transaction, off-line debit is settled by way of the ACHnetwork between the card issuer and the acquiring processor. Funds aregenerally available to the merchant on the next business day. These fundsare considered guaranteed because the issuing bank is debiting thecustomer’s account as it settles with the acquirer (or acquiring processor).


Off-line debit is priced like a credit card transaction: an interchange feebased on a percentage of the purchase is charged to the merchant. Theseinterchange fees are set by the card associations and are similar to thosecharged for credit card transactions. The industry average for off-line debit is1 to 3 percent of the purchase amount, which is paid by the merchant to theacquirer (or acquiring processor). This fee is called the merchant discount



fee. Out of this fee, the acquirer (or acquiring processor) passes along aninterchange and network fee to the national card association and issuingbank, respectively.

4-6.2 Suitability for Postal Service Use as an InternetPayment MethodOff-line debit offers both benefits and risks to the Postal Service. The majorbenefit is that the funds are good when they are authorized. The funds arethus guaranteed the next business day. There is little risk of NSF, as theremight be in lockbox or ACH debit transactions, because the issuing bankauthorizes the transaction based on funds availability at the time of thetransaction request. In addition, the risk of fraud is lower than for credit cardsbecause the lower credit limits make it less attractive to large-scale,sophisticated fraud schemes.

However, on the Internet, there is not always a way to authenticate that theperson submitting the order with the off-line debit card is the cardholder (if theissuer does not perform AVS); therefore the risk of fraud is higher. Also,compared to online debit, off-line debit is costly.

The Postal Service is currently required by the card associations to acceptoff-line debit because of their policy of honor all cards. The card associationsclaim that this is critical to the existence of their brands. An antitrust suit hasbeen filed by a group of major retailers against Visa and MasterCard for theright to refuse to accept off-line debit cards at credit card-accepting points ofsale. The Postal Service can continue to accept off-line debit cards forInternet payments, but only authorize those that meet Postal Service AVSrequirements — and still be within the limitations of Visa and Mastercardrules.

4-6.3 Authentication and AuthorizationCardholder authentication does not take place over the Internet today.Issuing banks do not support address verification for off-line debit, so thecardholder’s identity is not authenticated. Rather, the issuing bank, inresponse to a request for approval, provides authorization through thepayment association and the merchant’s acquiring institution.

4-6.4 Settlement DescriptionLike a credit card transaction, off-line debit is settled by way of the ACHnetwork between the card issuer and the acquiring processor. The acquiringprocessor compares the settlement file to its records and sends a Fedwire tothe Postal Service the next business day, representing the settled amount forthe previous business day.



4-6.5 Additional SecurityBecause the Postal Service is required to honor all cards, the same securityfor credit cards should be used for off-line debit cards. At a minimum, thePostal Service should require that all payment and billing information besubmitted by the customer to the Postal Service Web application, using anencrypted session supported by SSL (see Sections 2-1.2 and 4-7). Inaddition, for this and all payment types, the Postal Service should useanother encryption program that equals or exceeds triple-DES (dataencryption standard), to transfer the transaction data to the paymentapplication.

4-7 Credit Card

4-7.1 Transaction DescriptionCustomers can use credit cards to purchase goods and services by way ofthe Internet (see Exhibit 4-7.1a). Recent advances in Internet security andSSL (see Section 2-1.2) have improved the security of conducting Internettransactions. When a customer moves to the checkout phase of thetransaction, the Web server would require the Web browser to begin a securesession. Once the secure session is established, the customer can safelysubmit the purchase information required. In the checkout phase, once asecure (SSL) session is established, a customer enters the credit cardaccount number, expiration date, and billing address information. Thecheckout server should first verify the validity of the credit card number byapplying the check digit algorithm in accordance with ISO 2894. (If the checkfails, the number may have been entered incorrectly by the customer.) Thischeck step reduces the number of credit authorization requests and thereforereduces the cost of supporting credit card purchases.

In-band and out-of-band transactions are listed in Exhibits 4-7.1b and 4-7.1c.The payment system sends this information to the merchant’s (PostalService’s) credit card processor (the acquirer) to verify that the customer hasavailable credit, to authorize the transaction, and to compare the customer’sentered billing address to the actual information. The card processor thensends two codes back to the merchant: one authorizing the transaction andanother identifying which parts of the address information entered by thecustomer are correct. Based on business rules, the merchant’s system thendecides whether the transaction is accepted and provides the goods orservices to the customer.



Exhibit 4-7.1aCredit Card Payment Model

Issuing Bank(customer’s)

1.Credit card information (submitted during SSL encrypted session).

AcquiringBank/Processor

USPS Customer Merchant

Internet

Credit CardNetworks

3.Transaction confirmation.


4.Statement




Exhibit 4-7.1bCredit Card In-Band Transaction


From Postal � Data stored � Success or failure� Transaction ID or order number� Authorization number

� CC number� Expiration date� Transaction amount� AVS information� Merchant ID number� Terminal ID number� Order number

From Customer � Name� Type� Credit card number� Billing address� Expiration date� Ship-to address

(if different from the billing address)

From Processor � AVS code� Authorization number

Exhibit 4-7.1cCredit Card Out-of-Band Transaction


From Postal � Information stored� Reporting� Reconciliation information� Void in database� Accounting information

� Product delivery� Payment advice� History of transaction

� Credit request� Settlement file� Response to charge-back

From Customer � Void request� Credit request

� Request for charge-back

From Processor � Charge-backs� Reports� Money


The customer is required to have a credit card accepted by the PostalService. He or she must be able to provide address verification information tothe Postal Service, including billing street address and ZIP Code. Customersmust also have a Web browser that supports SSL (e.g., Netscape Navigator3.0 or higher or Microsoft Internet Explorer 3.0 or higher).




The Postal Service currently has a relationship with a major credit cardprocessor. The current implementation requires that the Postal Serviceestablish a new merchant identification number for each new product orservice that is offered.

In order to support the Web-based credit card transactions, the checkoutserver software must be written to obtain the information from the customer,perform a prepurchase authorization, and then conduct the transaction. Thecredit card information must be protected for the checkout and postpurchasephases of the transaction. Once the checkout server has received thecustomer’s payment information, the system must deliver it to the PostalService’s acquirer (merchant bank or processor) for clearance andsettlement. Internally, the Postal Service must establish a system to storecredit card transaction information for at least one year from the transactiondate.


Assuming that the settlement function occurs, funds from credit cardtransactions are sent to the Postal Service by way of Fedwire from the cardprocessor back-end and are available on the next business day. Creditcard-based transactions allow for charge-backs or credit requests from thecustomer after the initial transition.


The cost of using online credit card transaction processing is on the basis ofa per transaction cost (the discount rate multiplied by the value of thetransaction). Using the Address Verification System reduces the cost pertransaction to the Postal Service because it provides a minimal level ofauthentication of the cardholder for a card-not-present transaction.

4-7.2 Suitability for Postal Service Use as an InternetPayment MethodThe Postal Service currently accepts four major credit cards (Visa,MasterCard, Discover/Novus, and American Express) for purchases from itscatalog on the Internet. Credit card transactions are a suitable method foraccepting payment over the Internet. They are the most used method foraccepting payment from customers (for business-to-customer transactions)over the Internet today.



4-7.3 Authentication and AuthorizationAn Internet purchase is considered a card-not-present transaction. ThePostal Service provides authentication to protect the customer and the PostalService against fraud by using AVS to authenticate the customer’s accountlegitimacy. Exhibit 4-7.3 shows a sample address verification matrix that thePostal Service product manager is required to complete. This matrix allowsthe product manager to determine how much risk he or she is willing to take,based on the level of authentication and the value of the transaction.

The credit card processor, through its relationship with credit card issuers andmajor payment associations, receives information that credit is available onthe customer’s account. The credit card processor sends the authorization(that credit is available), along with a code representing address verification.The Postal Service then makes a decision based on the address verificationcode whether to allow a transaction that is authorized by the card processorto be completed.



Exhibit 4-7.3 (p.1)Address Verification System Matrix

Address Verification System Return Codes From the Credit Card Issuerand Related Action Codes

CardholderAddressand GivenBilling AreCompared FDMS

MasterCard Visa

AmericanExpress

Discover/Novus JCB

DinersClub

If TotalValue is< $100

If TotalValue is≥$100

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ActionCode

ActionCode

Addressmatch,9-digitZIP+4match

YY X Note 1 Note 1 Note 1 Note 2 Note 2

Addressmatch,5-digit ZIPCodematch

YY Y Y Y A Y Y Note 2 Note 2

Addressmatch, ZIPCodemismatch

YN A A A Y A A Note 2 Note 2

Addressmismatch,9-digitZIP+4 codematch

NY W Note 1 Note 1 Note 1 Note 2 Note 2

Addressmismatch,5-digit ZIPCodematch

NY Z Z Z Z Z Z Note 2 Note 2

Addressmismatch,ZIP Codemismatch

NN N N N N N N Note 2 Note 2

Cardnumber noton file

XX W Note 2 Note 2

Addressverificationunavailable

XX U U U U U U Note 2 Note 2

Retry orsystemunavailable

XX R R R R R Note 2 Note 2

Service notsupported

XX S S S S S Note 2 Note 2



Exhibit 4-7.3 (p.2)Address Verification System Matrix


CardholderAddressand GivenBilling AreCompared FDMS

MasterCard Visa

AmericanExpress

Discover/Novus JCB

DinersClub

If TotalValue is< $100

If TotalValue is≥$100

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ActionCode

ActionCode

Addressverificationnot allowedfor cardtype

XX E E E Note 2 Note 2

Addressverificationrequestedor notreceived

XX Note 2 Note 2

Notes:1. For Visa, American Express, and Discover/Novus the ZIP+4 is not applicable. Only the address and 5-digit ZIP

Code need to be sent for AVS.2. The product manager must decide whether to accept or reject the credit card payment, using the following action

codes:A = Accept Order; D = Decline Order; R = Retry Order Submission

4-7.4 Settlement DescriptionAt the end of the business day, a settlement file is generated and sent to FirstData Merchant Services (FDMS) with the following information about eachtransaction processed during the business day:

� Merchant ID and Terminal ID.

� Credit card number.

� Transaction date.

� Transaction amount.

� Authorization number.

� Credit card number.

� Preauthorization void status.

FDMS compares the settlement file to its records and sends a Fedwire to thePostal Service the next business day, representing the settled amount for theprevious business day. Reconciliation takes place at the MinneapolisAccounting Service Center (MNASC).

4-7.5 Additional SecurityBaseline security (see Chapter 2) is sufficient for credit card transactions inwhich the customer provides a credit card. However, if the Postal Servicewants to allow customers to store credit card account numbers on Postal



Service servers so that the customers do not have to reenter them each time,additional security is required. The Postal Service Web application may allowcustomers to establish user profiles in a way that payment information neednot be entered for each transaction. This would require that the Webapplication payment platform keep the payment information (credit cardnumber and billing and shipping information) on a server that has a very highlevel of security. For this model, the Postal Service would be required tomaintain the customer credit card information in encrypted form and on anapplication server that is both physically secure and is not directly accessiblefrom the Internet. Authorization could be done using passwords or digitalsignatures.

4-8 SET-Enabled Credit Card

4-8.1 Transaction DescriptionThe Secure Electronic Transaction (SET) protocol is the result of a jointventure between Visa and MasterCard and a number of technical partners.The SET transaction protocol has been designed to promote the marketacceptance of electronic commerce-related transactions. Specifically, Visaand MasterCard intended to offer a system that provides ease ofimplementation with minimal incremental impact upon either the merchant orcustomer. In addition, SET was designed with a bolt-on approach in mind thatallows it to be added to client applications without the need for majorupgrades of these systems. The SET protocol specifies how all parties in theelectronic transaction — cardholders, merchants, issuing banks, acquiringbanks, and processors — interact to ensure secure payment processing overthe Internet.

The SET protocol is restricted to payment cards or similar applications whereparties take on the role of customer, merchant, and acquirer. It does notaddress the actual transfer of funds between parties and relies on theexisting credit card infrastructure for settlement. To the cardholder, thesetransactions will appear like any other charge on their credit card statement;for the acquirer, this mechanism will be viewed as another mechanism thatcan leverage the current relationship with merchant customers.

As now implemented (see Exhibit 4-8.1a), the SET model closely follows theexisting issuer-acquirer model to which Visa and MasterCard now subscribe.As a first step in the process, both the merchant and the customer mustobtain the credentials and software necessary to operate within the SETenvironment. (See Exhibits 4-8.1b and 4-8.1c for in-band and out-of-bandtransactions.) Both parties must also complete a multistep process by whichboth the identity and authority of the parties are determined, as follows:

1. The consumer and merchant receive digital certificates from acertificate authority (generally their respective banks) prior to ordering.

2. The consumer verifies the legitimacy of a merchant, using thecertificates, and sends order and payment information.



3. The merchant authenticates that the customer is a legitimate creditcard holder and sends back a message confirming the order.

4. The merchant sends an encrypted payment authorization request to apayment gateway (operated by the merchant’s bank or a third-partyprocessor).

5. The gateway decrypts the message and verifies the merchant, order,and payment information.

6. The gateway then sends a traditional authorization request over theexisting credit card network to the customer’s bank. The customer’sbank then sends its response back across the credit card network tothe merchant’s bank or third-party processor.

7. The bank or processor sends the approval (or denial) to the paymentgateway, which encrypts the response and sends it back to themerchant by way of the Internet.

8. The merchant lets the customer know whether the purchase has beenapproved.



Exhibit 4-8.1aSET-Enabled Credit Card Payment Model


3.Merchantauthenticatesconsumer andreturns orderconfirmation.


Customer Merchant

1.CertificateAuthorityissues certificate.

1.CertificateAuthorityissues certificate.

2.Consumer authenticates merchant, then sends order confirmation.

4.Merchant sends authorization request to gateway.

8.Merchantinforms customerof approval.

6.Gateway sendsrequest to comsumer’s

financial institution via credit card.

7.Consumer’s financialinstitution sendsinformation backthrough gateway tomerchant.

5.Gateway verifies merchant order and payment information.

7.Consumer’s financialinstitution sendsinformation backthrough gateway tomerchant.

Credit CardNetworks

6.Gateway sendsrequest to comsumer’s

financial institution via credit card.

Exhibit 4-8.1bSET In-Band Transaction


From Postal � Any data to be stored internally

� Success or failure� Transaction ID or order number� Authorization number

� Authorization request� Payment instruction

From Customer � Payment instruction� Ship-to address

From Processor � Authorization Response� Capture token



Exhibit 4-8.1cSET Out-of-Band Transaction


From Postal � Any data to be stored internally� Reporting� Reconciliation� Void in database� Accounting information


� Credit request� Settlement file� Response to charge-back

From Customer � Void request� Credit request

� Registration agreement� Certificates

From Processor � Charge-backs� Reports� Funds transfer

� Registration agreement� Certificates

In the SET model, the merchant is never permitted to see the contents of thecustomer’s payment instruction (PI), which is encrypted in such a way thatthe acquirer’s public key is required to decrypt the message. Thisarrangement makes the handling of transactions considerably easier; it is notnecessary to consider the security of credit card information because theSET protocol protects this information from access by all intermediate parties.


Customers are required to download the SET digital wallet software from theInternet. (Browser developers are also planning to incorporate digital walletsinto new Web browser versions.) Also, customers will need a digital certificatefrom the CA of the card-issuing bank. In order for the bank to issue a digitalcertificate, customers must provide personal information that will beconfirmed by the bank and stored in the digital certificate.


The Postal Service will need to acquire a digital certificate representing itsSET account number and SET server software to store the digital certificate.The Postal Service will contact its bank (or establish an account at a bankparticipating in SET) to obtain its own SET digital certificate. The paymentsystem that a Postal Service product developer chooses must beSET-compliant.


The settlement function of SET is identical to that of a credit card payment.Funds are transferred to the Postal Service by its card processor throughFedwire. These funds would typically be available on the next business day.As with credit card transactions, reversals or credit requests from thecustomer are possible after settlement for the initial transaction has beencompleted.




At this time, the use of SET is primarily limited to small-scale pilots. As such,discount rates for the use of SET vary greatly, but can be generally describedin the same manner as a traditional credit card transaction. The cost of usingonline credit card transaction processing is on a per-transaction-cost basis(the discount rate multiplied by the value of the transaction).

4-8.2 Suitability for Postal Service Use as an InternetPayment MethodFor online purchases, SET provides a significant increase in security for boththe customer and the merchant. In addition, because the merchant is notprovided with the actual credit card information, SET shifts the burden ofmany risks and concerns surrounding the storage, accidental disclosure, ortheft of this information. Consequently, SET provides an ideal mechanism bywhich credit card payments can be accepted. There is significant doubt aboutthe future of SET, however, given the poor acceptance by Web vendors andfinancial institutions. Since financial institutions have not provided certificatesto customers on a wide-scale basis, there is also little customer awarenessof, or ability to use, SET.

4-8.3 Authentication and AuthorizationSET primarily relies upon x.509 digital certificates to provide a mechanism forauthentication within the protocol. A central authority issues these certificatesto both the customer and the merchant. These certificates provide mutualauthentication of the customer and the merchant and provide nonrepudiationof both origin and receipt.

4-8.4 Settlement DescriptionThe settlement function of a SET transaction is identical to that of a creditcard that does not use SET (see Section 4-7.4).

4-8.5 Additional SecurityThe SET protocol is a payment protocol. Applications that support thecustomer in the shopping phase must use the SET application programinterfaces (APIs) to ensure that the transaction conducted with the paymentengine is SET-compliant. This requires additional security in the front end ofthe system. For the checkout phase, SET uses mutual authentication withSET certificates, which differ from other x.509 certificates in that they makeuse of the extensions field to add specific attributes of the cardholders,namely a numeric quantity generated by using an algorithm that is stored onthe card and that represents the customer’s account number. A bank or therepresentative of a bank, rather than another trusted third party, issues thesecertificates.



4-9 Postal Service Postal Electronic Payment PlatformCache

The Postal Service is considering offering customers the opportunity to havean account, called PEPP Cache, with the Postal Service that would beavailable through the Internet and other channels as well. PEPP Cachewould be similar to, and replace, the trust accounts that customers maintainat local post offices or the CAPS accounts that are maintained centrally. Thisaccount structure will be created under Phase II of the Postal ElectronicPayment Platform project. The customer will be required to provideinformation to create the account and to be used for authentication when thecustomer wants to use the account. The customer could use various paymentmethods (described earlier) to add value or load the account: electronic orpaper lockbox, ACH credit, ACH debit, Fedwire, and (possibly) credit card.Loading an account should follow the same process as using any of thepayment methods to purchase products or services, as described in thishandbook. This section describes the transaction after the PEPP Cache isloaded.

4-9.1 Transaction DescriptionAfter the customer has selected an item to purchase on the Internet, thecustomer can choose the payment option of using his or her Postal Serviceaccount. The customer should be required to identify himself or herself to thepayment system by entering his or her Postal Service PEPP cache number,and a Postal Service password to be authenticated by the system. Thetransaction amount, identification, password, and account number arepassed to the Postal Service account system or database that authenticatesthe customer by way of the password, checks the customer’s accountbalance, and authorizes the transaction. This process should either put animmediate hold on the account for the amount spent or move the value to anew data file for settlement between Postal Service accounts.


The Postal Service PEPP Cache payment type requires the customer to havean account and a password. A Web browser that supports SSL is alsorequired.


The Postal Service holds the PEPP Cache on behalf of the customer. ThePostal Service must connect the PEPP Cache to its Internet Web paymentsystem so that the customer can ask to use the PEPP Cache while online,the request can be authorized, and the Postal Service can deduct thetransaction amount from the PEPP Cache.




Because PEPP Cache is prefunded, funds are available to the Postal Serviceimmediately and are guaranteed. Depending on how long the Postal Servicerequires between the time a check is received at a lockbox or an ACH debit isinitiated and the funds in the account are used, the Postal Service may be atsome risk for NSFs. The Postal Service policy should weigh the risk ofallowing customers to use the funds immediately versus the benefit ofease-of-use of the system by customers.


The Postal Service must maintain the system of accounts for the customers.This cost depends on the software, hardware requirements for scalability, andthe accounting resources required for reconciliation. There will also be somecost to the Postal Service to support the various methods of loading anaccount; however, the incremental cost for a transaction should be nominalbecause the Postal Service does not have to pay a third-party vendor toconduct the transaction on its behalf.

If the Postal Service chooses to use digital certificates in place of passwords(especially for higher-value transactions), the Postal Service or the customerwould have to bear the cost of purchasing and/or issuing the certificates.

4-9.2 Suitability for Postal Service Use as an InternetPayment MethodThe PEPP Cache would allow the Postal Service to provide its customerswith a convenient mechanism to make small-value purchases. It also allowsthe Postal Service to manage PEPP Cache and eliminate the risk of NSFs.

4-9.3 Authentication and AuthorizationAuthentication may be provided in two ways. For lower-value transactions,the customer provides the Postal Service with a user identification (randomlygenerated and sent to the customer) and a password. The user ID andpassword are checked against the system, and the customer isauthenticated. For higher-value transactions, the customer provides thePostal Service with a digital certificate that is used to authenticate thecustomer and the account. For medium-value transactions, the PostalService will have to conduct a risk analysis to determine what level of securityis necessary to protect the customer’s account and Postal Service revenue.

Authorization takes place within the account system. When the customersubmits an order (after the customer is authenticated), the account systemchecks funds availability in the customer’s account; if funds are sufficient, thetransaction is authorized.



4-9.4 Settlement DescriptionSettlement takes place within the Postal Service’s account systems. Once thetransaction has occurred, the Postal Service accounting system must movefunds from the customer’s PEPP Cache account to the appropriate generalledger account of the product or service that the customer purchased. ThePostal Service already has the funds within its possession. Refunds andvoids are handled according to the PEPP Cache requirements.

4-9.5 Additional SecurityThe deposit-and-pay-down method raises the issue of ensuring that only thecustomer who deposits the money can access the online PEPP Cache. Forlow-value transactions, the use of SSL server-based encryption plus basicauthentication (user ID and password) would be sufficient security and wouldnot be encumbered by the additional system administration required tosupport digital certificates. This process would be as follows (both methodsinvolve specialized coding of the Web application):

� The customer decides to use the PEPP Cache payment system.

� The customer downloads instructions for paying into the account.

� The customer fills out an online account form.

� The Postal Service creates an account on the Web application with arandom user ID and password. User ID and password are sent to thecustomer by way of electronic mail. (In addition, processes are neededto allow the customer to change the password and to provide thepassword out-of-channel to a customer who loses his or her password.)

� The customer receives the user ID and password by mail and loads hisor her PEPP Cache account using an allowable payment method.

� The customer makes selections from the Web application shoppingpages.

� The customer moves to the checkout phase and establishes anSSL-encrypted session with the Web application checkout server.

� The customer selects the PEPP Cache payment method, provides hisor her user ID, password, and account information.

� The Postal Service checks the user ID and password, as well as fundsavailability. If all parameters match, the goods or services are delivered,and the customer’s PEPP Cache is debited.

The most efficient method of handling the risk of ensuring that the customer’saccount is secure is to use personal digital certificates. The Postal Servicemight consider digital certificates to ensure that only the customer whodeposits the money can access the account, especially for larger-valuetransactions in which the risk of loss to the customer is greater.

4-10Payment Types and Methods


Use of personal digital certificates would restrict the user to the Web browserfor which the certificate is applied. (This is not a suitable setup for users ofpublicly available Internet access points such as libraries or schools.) Thedigital certificate application process is as follows:

� The customer decides to use the PEPP Cache payment system.

� The customer applies for PEPP Cache and a personal digital certificate.During the application process, the Postal Service certificate authoritysends a serial number that will be used by the customer to link theaccount with the certificate.

� The Postal Service registration authority generates a personal digitalcertificate for the customer and e-mails the instructions for accessingthe personal certificate. This is secure because only the Web browserthat generated the private key will be able to load the personalcertificate issued by the Postal Service.

� The customer installs the personal certificate and makes goods orservices selections from the Postal Service Web application.

� The customer proceeds to the checkout phase and selects the PEPPCache payment method.

� The Web application payment server will automatically ask thecustomer to present a personal digital certificate to access accountinformation.

� The customer presents his or her personal certificate. If accepted, thePostal Service Web application processes the transaction, deducts thecost from the customer’s PEPP Cache, and authorizes delivery ofPostal Service goods or services to the customer.

4-10 Digital Cash (CyberCash example)CyberCash is a third-party service provider that specializes in providingsecurity for transactions conducted over the Internet. It is the most widelyavailable digital cash scheme in the U.S. for Internet transactions. CyberCashuses separate software for the merchant server and for the customer Webbrowser to submit the details of a financial transaction securely after theterms of the transaction have been agreed upon by both parties. Exhibit 4-10illustrates the CyberCash payment model. The service works with NetscapeNavigator version 2.0 and lower and Microsoft Internet Explorer version 3.0and lower.

No form of Internet-based digital cash is currently supported by the PostalService.



Exhibit 4-10CyberCash Payment Model

CustomerWallet

Merchant Bank

Clearing details

Payment details

Purchase details

Customer shopping

Merchant Web Serve rWeb Browser

Customer Card-Issuing Bank

Paymentinformation

Registrationcard binding

Paymentinformation

CyberCashServer

InternetInternet

Bank Network

MerchantSoftware

4-10.1 Transaction Description


CyberCash users can designate Visa, MasterCard, American Express,Discover, and debit cards, as well as personal bank accounts, as the sourceof funds for the CyberCash wallet (registration is by way of fax). In all cases,the CyberCash payment service acts as an intermediary between thecustomer and the merchant, providing a secure means of transferringpayment information from the customer to the merchant. (Exhibit 4-10.1.1aand Exhibit 4-10.1.1b describe the in-band and out-of-band transactionflows.)

The customer is required to download the CyberCash wallet application,which is reasonably easy to use and makes up for the security deficiencies inthe early Web browser software. The customer must have the CyberCashwallet software loaded and an Internet browser to make purchases usingCyberCash. CyberCash also supports micropayments through the CyberCoinsystem. CyberCoin allows a CyberCash user to charge dollar amounts to his



or her credit card that are then placed in the CyberCash wallet and can beused to make purchases below $20.

Exhibit 4-10.1.1aCyberCash In-Band Transaction

To Postal To Customer To CyberCash

FromPostal

� Internal audit data

� Item� Price� Transaction ID� Receipt for transaction� Postal and customer data must match

� Card details from CyberCash wallet (encrypted with CyberKey)� Payment type� Account number to debit� Credit account� Item� Price� Transaction ID

FromCustomer

� Card details from CyberCash wallet (encrypted with CyberKey)� Payment Type� Account number to debit� Item� Price� Transaction ID

� Personal record of transaction

FromCyberCash

� Charge action response� Payment advice� Postal receipt� Customer receipt

� Transaction details



Exhibit 4-10.1.1bCyberCash Out-of-Band Transaction

To Postal To Customer To CyberCash

FromPostal

� Information stored� Reporting� Reconciliation information� Void in database� Accounting information


� Merchant bank account

FromCustomer

� Void request� Credit request

� Transaction history

� Registration� CyberCash wallet setup� Credit card bindings

FromCyberCash

� CyberCash merchant connection kit (MCK)� CyberCash CyberKey

� CyberCash wallet software� Software updates� Merchant lists� CyberCash CyberKey

� Internal audit data


The Postal Service is required to have a merchant account with a CyberCashfinancial partner (e.g., Unified Merchant Services or Bank of America) and toload and configure the CyberCash software (merchant connection kit —MCK) to accept CyberCash payments.


If credit is available in the customer’s credit account (through the issuingprocessor), the transaction is authorized and the customer is allowed topurchase the goods. Settlement occurs through the traditional credit cardpayment networks at the end of the day, and the Postal Service merchantbank receives payment the next business day. The funds are guaranteed;Cybercash takes on the risk.


The CyberCash MCK software is free, once a merchant bank account isacquired. CyberCash charges an additional fee on top of the merchantinterchange fee for each transaction. For the Postal Service, this means thatCyberCash, which is another method for customers to use credit cards, isincrementally more expensive than the Postal Service accepting credit cardsdirectly. The transaction costs for the CyberCash payment system is notefficient to use for payments under $10, similar to credit cards.



4-10.2 Suitability for Postal Service Use as an InternetPayment MethodThe CyberCash application is redundant, less secure, and more expensiveper transaction than using credit cards. CyberCoin is essentially a storedvalue account held by CyberCash. CyberCoin supports micropayments, butshares the same limitations as CyberCash. The Postal Service shouldconsider using its own account before examining this payment mechanism.

4-10.3 Authentication and AuthorizationThe customer signs on to his or her wallet using a CyberCash-provided userID and password. CyberCash, not the Postal Service, authenticates thecustomer. Security is provided by the proprietary customer, the PostalService, and CyberCash public or private key pairs. The first message is sentfrom the merchant (Postal Service) to the customer and signed with themerchant’s private key. The customer agrees to the transaction, selects apayment card from the CyberCash wallet, signs the transaction agreement,and then encrypts the entire package using the CyberCash server public key.The encrypted message is sent to the merchant, who then forwards it to theCyberCash server, which decrypts the message and verifies the signatureson the message from the customer and the merchant. The CyberCash serverthen clears the transaction with the processor (bank) and returns unsignedreceipts for the merchant and the customer to the merchant.

The CyberCash gateway server performs checks for funds availability at thetime of the purchase and thus provides authorization, through the paymentnetworks and issuing bank.

4-10.4 Settlement DescriptionOnce a transaction is complete, the CyberCash credit card acquirer and thecustomer’s issuer settle. The CyberCash acquirer sends a Fedwire to themerchant’s acquiring bank the next business day. CyberCash merchantsoftware supports voids and returns.

4-10.5 Additional SecurityCyberCash provides all software for secure transactions. The customer’saccount numbers are stored encrypted in the wallet.



4-11 Financial Services Technology ConsortiumThe Financial Services Technology Consortium (FSTC) is a consortium ofbanks, financial service providers, national laboratories, universities, andgovernment agencies that sponsor and participate in noncompetitivecollaborative research and development of interbank technical projects.FSTC has developed a standard for implementing check transactions overthe Internet. The electronic checkbook (E-Check) uses client software toemulate a paper checkbook and Internet electronic mail to transport checksfrom the customer to the client. Electronic mail is also used to forwardendorsed E-Checks from the merchant to the banks for clearing. Security isprovided by public key cryptography stored on smartcards used by thecustomer, merchant, and bank. The E-Check system is currently in pilotphase with the U.S. Department of the Treasury, the Department of Defense(DoD), several participating DoD contractors, and BankBoston. It is unlikelyto be used by small-scale users in the near future; however, as expanded useof the E-Check system evolves, larger corporate accounts may use thesystem to handle large transfers.

4-11.1 Transaction DescriptionThe FSTC Electronic Checkbook is modeled after the paper check systemand has the look and feel of a checkbook. Each electronic check containspayment information (date, payee, payee’s e-mail address, amount, memo,and attachment) and is written and signed electronically using the private keyof the sender and the public key of the bank. There are four paymentscenarios for E-Checks:

� Deposit-and-clear.

� Cash-and-transfer.

� Lockbox.

� Funds-transfer.

The E-Check is sent by way of electronic mail from the payer (customer) tothe payee or merchant (Postal Service) to complete the transaction. E-Checkuses a smartcard (hardware-based) personal digital signature to sign thechecks written by the customer. The smartcard contains the digital certificateof the customer, the public key of the issuing bank, and the public key of theissuing bank’s certificate authority. When the customer writes a check, thesmartcard is inserted and the E-Check application prompts the customer for aPIN. The customer then enters the PIN. If the PIN is correct, the E-Checksoftware signs the check with the customer’s digital certificate. The E-Checksystem assumes that a public key infrastructure is in place to support it. Eachscenario closely models the paper-based checking account.

Smartcards are widely regarded to be a secure mechanism for storing andprotecting electronic data. By their very design, they are inherently secure.Although the chips that run them are quite simple, they are tamper-resistantand include monitoring devices to determine whether the chip has beencompromised.




The customer must have the E-Check software, a smartcard reader, anaccount with a bank participating in the E-Check program, a personal digitalcertificate issued by the bank embedded in the smartcard, and the PINnumber for the smartcard. E-Check is much less convenient than otherpayment methods for the customer to use for purchasing Postal Serviceproducts (unless the customer has other uses for the smartcard). In all cases,the customer’s bank must also support E-Check.


Exhibit 4-11.1.2 summarizes the merchant (Postal Service) and bankrequirements for using E-Check. For the deposit-and-clear model, the PostalService must be able to accept and forward E-Checks, and the PostalService bank must be able to process E-Checks received by way of theInternet. For the lockbox model, the Postal Service bank must be able toreceive and process electronic checks. The cash-and-transfer andfunds-transfer models require that only the customer’s bank be able toperform E-Check transactions. Exhibit 4-11.1.2 identifies the parties thatparticipate in each of the E-Check models:

Exhibit 4-11.1.2Bank Requirements for E-Check

E-Check Model Postal ServicePostal Service

BankCustomer

Bank

Deposit-and-Clear Yes Yes Yes

Cash-and-Transfer Yes No Yes

Lockbox No Yes Yes

Funds-Transfer No No Yes

The Postal Service would be required to have software set up to transform acustomer’s shopping selections into an invoice that is either downloaded fromthe Postal Service Web application or sent by way of e-mail from the Webapplication to the customer. The deposit-and-clear and cash-and-transfermodels are presented here in detail because they are the likely forms ofE-Check to be implemented by the Postal Service.

4-11.1.3 Deposit-and-Clear Model

The deposit-and-clear transaction (Exhibit 4-11.1.3a) follows the paper checkmodel very closely. The merchant provides the customer with an invoice forgoods or services.

The customer then opens the E-Check application, writes an E-Check to themerchant, and signs it, using the digital certificate contained in the customer’ssmartcard. The E-Check is then encrypted, using the public key of thecustomer’s bank. The customer delivers the check to the merchant by way ofelectronic mail. The merchant adds an electronic deposit slip and affixes adigital signature to the new document containing the original E-Check (stillencrypted) and the invoice. The entire package is then sent, by way ofelectronic mail, to the merchant bank (if the merchant bank is a participating



E-Check bank). Data flows for deposit-and-clear in-band and out-of-bandtransactions are explained in Exhibits 4-11.1.3b and 4-11.1.3c.

Exhibit 4-11.1.3aFSTC E-Check Deposit-and-Clear Model

Merchant

1. Invoice


Customer


2. E-Check

7. Statement 3. Deposit slip& E-Check

6. Report

5. Automated cleaninghouse

4. Check clearing

Exhibit 4-11.1.3bE-Check Deposit-and-Clear Out-of-Band Transaction


FromPostal


� Product delivery� Payment advice

� Settlement File� Response

FromCustomer

� Balance checkbook

� Account setup� Void request

FromProcessor

� Monthly statement


� Reporting� ACH data



Exhibit 4-11.1.3cE-Check Deposit-and-Clear In-Band Transaction


FromPostal

� Data stored � Invoice� Order number

� Deposit slip (amount)� Endorsement� Postal digital signature, encrypted with the Postal Service’s bank’s public key

FromCustomer

� Date� Payee (name or electronic mail address)� Amount� Check number� Memo� Text document attached� Bank name� Account number� Customer digital signature, encrypted with bank’s public key

� Date� Payee� Amount� Check number� Memo� Text document attached

FromProcessor

� E-Check clearing information� Payment advice

4-11.1.4 Cash-and-Transfer Model

The cash-and-transfer model covers the case in which the merchant acceptsE-Checks, but the merchant’s bank does not (see Exhibit 4-11.1.4a). In thiscase, the customer sends the E-Check to the merchant, who then endorsesthe check, signs and encrypts it with the public key of the customer’s bank,and sends it to the customer bank by way of electronic mail. The customerbank decrypts the check, sends payment advice to the merchant, debits thecustomer’s bank account, and sends an ACH funds transfer to themerchant’s bank account. The merchant bank then sends a report to themerchant, notifying the merchant of a deposit. Data flows for thecash-and-transfer in-band and out-of-band transactions are explained inExhibits 4-11.1.4b and 4-11.1.4c.



Exhibit 4-11.1.4aSTC E-Check Cash-and-Transfer Model

Merchant


Customer


1. Invoice

2. E-Check

5. ACH credit

4. Payment advice

7. Statement 6. Report

3. Endorsement E-check



Exhibit 4-11.1.4bE-Check Cash-and-Transfer In-Band Transaction


FromPostal

� Data stored � Invoice� Order number

� Endorsement� Postal digital signature, encrypted with customer bank’s public key

FromCustomer

� Date� Payee (name or electronic mail address)� Amount� Check number� Memo� Text document attached� Account number� Customer digital signature, encrypted with bank’s public key

� Date� Payee� Amount� Check number� Memo� Text document

attached

FromProcessor

� Payment advice� E-Check clearing information

Note: For the cash-and-transfer scenario, the processor is the customer’sbank.

Exhibit 4-11.1.4cCash-and-Transfer Out-of-Band Transaction


FromPostal


� Product delivery� Payment advice

� Settlement file� Response

FromCustomer

� Balance checkbook

� Account setup� Void request

FromProcessor

� Monthlystatement


� Reporting� ACH data




In all three cases, funds availability is determined during ACH clearing andthe check-clearing process. Funds will generally be available on a next-daybasis. The funds are not guaranteed until they move through the entire ACHprocess.


The cost to the Postal Service depends on which model(s) the Postal Servicedesires to support. E-Check is not widely implemented at the customer level.The Postal Service should implement the lockbox model first, replace thepaper-based lockbox model it currently supports following the DoD pilot, andexpand its use of E-Check as required by its customers.

4-11.2 Suitability for Postal Service Use as an InternetPayment MethodThe E-Check system, when fully implemented, is suitable for use by thePostal Service as an Internet payment method. It provides a convenient andsecure method for transferring small and large amounts of money across theInternet and is suitable for use by both corporate and consumer customers.

4-11.3 Authentication and AuthorizationIn all cases, authentication is provided by the smartcard and PIN issued toeach of the parties to the transaction. This is considered adequate protectionfor the locally stored customer and merchant data.

4-11.4 Settlement DescriptionSettlement of E-Checks in all cases is by way of ACH. The banks supportingthe E-Checks will have to provide an interface mechanism from the E-Checkto the ACH such that, when an E-Check is presented for payment by way ofthe Internet, an electronic payments handler (EPH) receives and processesthe E-Check. The EPH would receive the E-Check, decrypt the check, verifyfunds availability, and create an ACH transfer to support the transaction.Voids or requests for credit are handled like voids or requests for credit withpaper checks.

4-11.5 Additional SecurityThe E-Check system requires no additional security. Digital certificates storedon smartcards provide security. This is adequate for the storage of thecustomer’s banking information on the customer’s personal computer; thetransmission of the E-Check; and the processing of the E-Check at themerchant site, merchant bank, and customer’s bank.



4-12 Bank Internet Payment SystemThe Bank Internet Payment System (BIPS) specification is a nonproprietaryprotocol for sending payment instructions safely over the Internet. It includesa specification for a payment server to enable processing of the paymentinstructions. It has been tested in prototypes with three banks. BIPS requiresthree components:

� A Network Payment Protocol (NPP) to enable the communication ofpayment instructions between the bank’s customer and the bank.

� A BIPS server to receive the request for payment, handle security,create the payment transaction from the request, and route thepayment transaction to the appropriate bank.

� A client application to create and send instructions, using the NPP.

4-12.1 Transaction DescriptionThe BIPS transaction takes place between the customer and the customer’sbank. The merchant must first present a bill or invoice to the customer. Theinvoice presents the merchant’s bank account number. The customer thennotifies the merchant that the payment will be initiated through BIPS. Thecustomer must have a certificate and digital signature capability providedand/or maintained by the bank. The BIPS server uses, but does not manage,a public key infrastructure.

If the customer chooses a push transaction (see Exhibit 4-12.1), thecustomer sends a payment instruction to the customer’s bank through eithere-mail or the Internet. The BIPS server validates the signature and certificate,sends an acknowledgment to the customer, and formats a message for thebank’s clearing-and-settlement system. The customer’s bank then sends, orpushes, an ACH credit, using the existing bank payment system. Themerchant’s bank then advises the merchant that the money has arrivedthrough its normal channels. Finally, the customer’s bank informs thecustomer that payment has been made.

If the customer chooses a pull transaction, the customer sends authorizationand BIPS payment instructions to the BIPS server at the merchant’s bank.The instruction will include the customer’s digital signature and certificate.The BIPS server automatically determines the settlement method based onthe selected cost and time. The payment instruction is then translated by theBIPS server into the appropriate bank payment processing systemtransaction to pull funds from the customer’s bank to the merchant’s bank.



Exhibit 4-12.1BIPS Push Transaction


1.Sends invoice/bill to customer.


Customer Merchant

Internet

2.Initiatespaymentinstruction.

4.Sends ACH usingexisting payment systems.

5.Informsmerchant thatpayment hasbeen received.

Internet

3.BIPS server validates signature andformats message for bank’s clearing.


To use the BIPS system, a customer will need to obtain a digital certificatefrom the customer’s primary DDA bank. The customer will also need a BIPSclient, which is an application that interfaces to the BIPS server or that cansend messages to the BIPS server. In addition, the customer will have to usebanking services from a bank that has a BIPS server.


The Postal Service will have to provide information about its bank (includingaccount numbers) to the customer so that the customer can use a BIPSpayment method. If the pull method is preferred in Internet commerce, thePostal Service will need to ensure that its bank is a BIPS bank. If the PostalService prefers the push method, its bank is not required to have anyadditional servers to accept transactions initiated through BIPS.

One important consideration for the Postal Service is the process by whichBIPS would be used for online transactions that have real-time fulfillment.The Postal Service will not receive notification that the customer has initiateda payment to the Postal Service until the next business day, when ACHsettlement has occurred. The pull transaction presents less risk to the Postal



Service because the Postal Service’s bank initiates a pull from the customer’saccount. However, either scenario requires the Postal Service to matchpayment information that is received the next business day with transactioninformation that occurs during day zero. See Exhibit 4-12.1.2.

Exhibit 4-12.1.2BIPS Transaction


FromPostal

� Transaction data

� Invoice� Account information

FromCustomer

� Notice of payment being sent by way of BIPS

� Invoice amount� Digital signature� Payment instructions

FromProcessor

� Notification of payment received

� Digital certificate� Acknowledgement of payment instruction received� Notification of payment sent

� ACH payment to merchant’s bank


BIPS is settled using traditional banking methods such as ACH debit (pull)and ACH credit (push). Funds are generally available to the merchant thenext business day.


The cost to the Postal Service should be the same as ACH credit or ACHdebit described above. The Postal Service’s bank may be required to have aBIPS server for the Postal Service to initiate pull transactions. The bank mayattempt to pass some of the costs to develop, operate, and maintain theserver back to the Postal Service.

4-12.2 Suitability for Postal Service Use as an InternetPayment MethodBIPS in its current form is more appropriate for an online bill paymentscheme than for an Internet pay-for-service scheme. It does not currentlysupport real-time payment. If a customer desired to pay using BIPS, thePostal Service would have to trust that the customer, upon completion of thetransaction with the Postal Service, would go to his or her bank’s Web siteand initiate a payment transaction to the Postal Service. Even if the BIPS pullmodel is used, the customer, not Postal Service, must send the paymentinstruction to the merchant’s bank to initiate an ACH debit. While this is likelymore desirable than the push model, it still does not provide real-timeverification of sufficient funds in the customer’s account. To this end, it is



most suitable for Postal Service applications where real-time fulfillment is notrequired. Alternatively, BIPS is suitable for large customers who want to payusing an electronic method other than electronic data interchange (EDI).

4-12.3 Authentication and AuthorizationAuthentication takes place between the customer and the customer’s bank inthe push scenario and between the customer and the merchant’s bank in thepull scenario. The BIPS model assumes that the bank or a third party issuescustomers x.509v3 digital certificates and that the digital certificate validationis open to either bank to verify the identity of the customer. The authorizationis provided by the payment instruction.

4-12.4 Settlement DescriptionSettlement occurs for BIPS as it does for ACH credit and debit. BIPS is apayment protocol that defines message transaction and formats, but rests onthe existing payment systems for settlement.

4-12.5 Additional SecurityBIPS requires authentication, using digital certificates to positively identify theparties involved in the BIPS communication. BIPS assumes that these digitalcertificates are issued by a bank (or other third party providing services to thebank) that acts as a certificate authority. Certificates would be issued to aBIPS client after verification of the identity of the person requesting the digitalcertificate. It is not envisioned by the BIPS specification that the merchantwould have any involvement in the issuance of certificates. BIPS requirespublic key encryption, digital certificates, and digital signatures for paymenttransaction security. BIPS also requires physical and electronic security forthe BIPS servers that would be located at bank facilities.

5Accounting Requirements


5 Accounting Requirements

Accounting has certain requirements for any new or existing initiative in whichpayments are accepted. These requirements address the fiscal andaccounting integrity and accountability of the payment flows and are intendedto ensure that back-end settlement, reconciliation, and reporting needs aremet. These requirements are met among the mainframes across the SNAnetwork in Raleigh, and in the accounting service centers (ASCs) of SanMateo and Minneapolis, protected from outside threats by existingsystemwide mechanisms and policies for protecting data storage and datatransport. However, the design of payment acceptance and authorizationprocesses must consider the need to capture, store, summarize, andtransport the data needed to support accounting requirements and processesthat may take place at the Minneapolis ASC, San Mateo ASC, and St. LouisASC. The importance of defining and designing-in accounting requirements isvital. Out-of-balance conditions often provide indicators of compromises tothe payment system; however, if accounting requirements are improperlydesigned and implemented, the system may produce false indicators ofsecurity or fraud problems.

The accounting requirements focus on the following six areas:

� Settlement data — The payment system must capture and forward thedetailed and summary data needed to settle each business day. Thesedata are used externally by the financial services provider to determinethe daily settlement amounts that form the basis for Fedwire or otherforms of funds transfer to Postal Service accounts.

� Reconciliation data — The payment system is the source of the dataneeded by accounting to ensure that net payments received can beaccounted for and balanced.

� General ledger data — General ledger values are required for alltransactions.

� Revenue allocation data — Product implementation will involve variousbusiness units, and sales (and cost) data must be reported in a mannerthat ensures accurate allocation to the field by ZIP Code. StandardField Accounting System and Statement of Account requirements andother applicable requirements contained in Handbook F-1, Post OfficeAccounting Procedures, must be considered.

� Customer report generation data — In certain cases, products mayrequire that customers be able to view their account status online. Thepayment system is the source of data needed to be able to createthese customer status reports.



� Exception tracking, tracing, and reporting data — Exceptions focus onchanges in transaction status due to the nonavailability of payment or achange in the customer’s decision to purchase a product or service.These credit and debit changes may take the form of a chargeback, areversal, or a request for credit. E-Check and lockbox transactions mayresult in NSF. ACH debit is subject to a 60-day revocation period. Eachpotential exception must be identified, tracked, and accounted for ateach of the processing stages.

5-1 Accounting Requirements Design QuestionsThe following questions are intended to serve as a checklist when specifyingthe full, end-to-end payment requirements for a product or service.

5-1.1 Revenue Flow� How will products or services be classified — account identifier code

(AIC), general ledger account (GLA), or Postal System Financial Report(PSFR)? Does the product fit into existing codes, or will new codesneed to be established?

� Is the total sale considered revenue? If not, when will revenue berecognized (i.e., when will the sale change from being as a liability tobeing recognized as revenue)?

� What portion of the sale is considered revenue?

� Who will receive credit for the revenue, a field office or a specificprogram? If it is a program, to which finance number should it becredited?

� Who will be responsible for reconciling the revenue account, a fieldoffice or an ASC?

� Who will process invoices? Minneapolis ASC? St. Louis ASC?

� How often will invoices be processed?

� What type of data will the Minneapolis ASC need to reconcile?

5-1.2 Payment Flow� What form of payment will be accepted?

� How will the Minneapolis ASC track funds received from settlement?

� What kind of reconciliation process will be available to reconcile withthe information created in the Web and database servers?

� Who will absorb expenses, a field office or a specific program? If it is aprogram, to which finance number should it be expensed?

� How will revenue be reported? How often? In what format?

5-1.5Accounting Requirements


5-1.3 Refunds� Will refunds be offered?

� Who will authorize refunds?

� How will refunds be tracked?

� Who will absorb the expense, a field office or a specific program? If it isa program, to which finance number should it be expensed?

� Who will process refunds?

5-1.4 Cost� Has a finance number been set up to track costs? What is that finance

number?

� Are accounting resources required? If so, for what purpose? Howmany?

� Is equipment (hardware, software, etc.) needed? If so, what is the cost?

� Is training required? If yes, who will absorb the cost of training?

5-1.5 Customer Service� Is a customer support center needed to support this initiative?

� Where will it be located?

� Who will be responsible for supporting customer service onpayment-related functions?

6-1Risk Assessment Guidelines


6 Risk Assessment Guidelines

The establishment of any information system requires an analysis of the risksassumed by the Postal Service in operating the system. Internet-accessiblepayment systems incur operational, financial, reputational, and legal risks.The Postal Service must consider the following primary factors in balancingthe risks of using a system with the business requirements for the system:

� Who is the customer?

� How well is the customer known or trusted?

� What are the value and frequency of the transactions by the customer?

When evaluating the risk of implementing a payment system and integratingit with an Internet-accessible system to support electronic commerce, it isimportant to consider the potential impact that the payment system has onthe overall security of the system. Once the risk is known and understood, aninformed decision can be made whether to accept a payment system for agiven product or service based on the customer and transaction criteria, thebusiness need, and the cost of implementing the security features required toprotect the transaction information. The risk assessment guidelinespresented here are designed to augment the requirements of HandbookAS-805, Information Systems Security (April 1994), section 83, addressingthe specific requirements to support an online payment system.

6-1 Handbook AS-805 RequirementsHandbook AS-805 requires a risk assessment for critical Postal Servicesystems. It outlines general guidance for developers to complete a riskassessment. This section augments Handbook AS-805 and providesdevelopers with a framework to evaluate the available electronic paymentssystems and select the payment methods based on the risks associated withthe payment type. Some criteria pertain to the components that support theelectronic payments system, while others pertain to the overall paymentmethods. When evaluating the risks of implementing the payment method foruse, it is important to consider whether changes to support the paymentsystem affect the security of the existing system.

As outlined in this handbook, the Postal Service Web application comprisesthree major and distinctly separate subsystems:

� Customer — The hardware and software used by a Postal Servicecustomer.



� Web interface — The hardware and software Internet interface to thePostal Service Web application.

� Back-office — The financial network hardware and software interface tothe Postal Service Web application.

The following supporting elements are required for the successful low-riskoperation of the Postal Service Web application:

� Server operating systems.

� Postal Service network or firewall configurations.

� Web server configuration.

� Certificate authority, registration authority, or public key infrastructure.

Each subsystem is different and has different requirements for risk analysis.Handbook AS-805, section 83, separates application and site riskassessment components. Site risk assessments evaluate the levels ofadministrative, technical, and physical security safeguards required tooperate the system at an acceptable risk level in its physical setting.Application risk assessments identify the application function, frequency ofprocessing, time-critical considerations (criteria), vulnerabilities, threats,costs, and information sensitivity. Risk cost is determined by assessingvulnerabilities, threats, and potential loss against the cost of systemssafeguards (in terms of monetary cost, impact on performance, and othersystem and network safeguards) and cost to the customer. These guidelinesare designed to provide criteria for application risk assessment and to includepossible measures to reduce the risk of the vulnerability.

6-2 Identification and Analysis of Risks to ElectronicPayment Systems

This section defines the various risk categories and identifies the potentialvulnerabilities and threats to the electronic payments system from each of therisk categories.

6-2.1 Operational RiskOperational risk is concerned with the reliability, integrity, and security of thesystems, applications, and information that are used during an electronicpayment transaction. These security controls are the most important controlsthat exist in these systems because they are subject to both internal andexternal attacks. The migration of information technology toward distributedarchitectures has resulted in increasingly complex security controls. For thisreason, it is imperative that care be taken in the design and implementationof a payment system to ensure that proper controls are in place. Issues suchas customer misuse and theft of confidential information arise here.

Unauthorized access could lead to direct losses, added liabilities tocustomers, reputational loss, or other problems. In addition to these costs,there may also be costs associated with repairing, rebuilding, or redesigninga compromised system.

6-2.1.2Risk Assessment Guidelines


6-2.1.1 Security Risks

When examining the operational risks that may be present, the controls overcritical accounting and risk management systems should be considered.Specifically, any policies, procedures, and technology controls implementedto protect these systems must be adequately designed to preventcompromise by either an internal or external attacker. Often controls aredesigned that are effective in preventing an external attacker fromcompromising a system, with little or no consideration of possible attacksfrom internal parties (e.g., employees or contractors). It is necessary toexamine all access paths to a system, both external and internal, todetermine where possible risks may exist. External data or systemdependencies may be areas in which these risks may be overlooked orignored.

For example, a system upon which inadequate controls have beenimplemented could be compromised by a successful attack from the Internet.Through this compromise, the intruders could have access to confidentialtransaction data such as credit card numbers and shipping information. Thisinformation could be used to defraud either the Postal Service or thecustomer through unauthorized purchases at the Postal Service orelsewhere.

With respect to controls relating to internal threats, employees should nothave access to all systems that support the purchasing and paymentprocess. Separation of duties should be ensured to prevent a single partyfrom having access to both purchasing and auditing infrastructure. This wouldprevent an unscrupulous employee from obtaining information about acustomer purchase (such as credit card information), creating a fraudulenttransaction using this information, and then removing any audit trail that hadbeen created regarding this transaction.

It is possible that inadequate controls could cause compromises that allow anintruder to install a virus or a probe of monitoring software on a PostalService server. Although either problem could create problems for the PostalService, installing monitoring software could allow an intruder to monitortransactions and thus greatly increase the damage that a single intrusionwould cause because of the volume of information that could be released.

6-2.1.2 Systems Design, Implementation, and Maintenance

The Postal Service can be exposed to risks if the systems that are used in anelectronic commerce venture are poorly designed or implemented. Risksrelating to the interruption of service or to poor performance can arise in suchcases. Some types of risk are well beyond the control of the Postal Serviceand may not have a complete remedy. For example, it is not possible for thePostal Service to design a system that will be completely immune to theeffects of Internet congestion. Although it may be possible to implement asystem that uses multiple network service providers and thus providesmultiple paths to the Internet, congestion on the customer’s Internetconnections cannot be completely prevented.



The Postal Service should ensure that systems are designed in a mannerthat provides best practice architecture to try to ensure that connectivity isprovided in nearly all cases. It is not possible, however, to completelyeliminate risks presented by reliance on a third-party service provider.

Another often overlooked risk, particularly important when examiningemerging payment strategies, is that of technological obsolescence. With thecurrent pace of advancement of technology, many products experience lifecycles that are considerably shorter than the life cycles ofnon-computer-related technologies. Frequently, even with rapid prototypingand development strategies, new products, methods, or technologies areavailable by the time the products are brought to market. In some cases,flaws are found in the technologies and they are replaced within atwelve-month period. As such, many systems that are being deployed todaycould be considered emerging or immature technologies. Risk results fromthe operational problems associated with such systems.

6-2.1.3 Customer Misuse of Products and Services

In the design and implementation of electronic payment systems, it isimportant to ensure that it is not possible for a customer to intentionally orunintentionally misuse the systems or services offered. For example, it isimportant that transactional information be obtained and stored in such amanner that adequate evidence of nonrepudiation is captured. Without suchevidence, it would be possible for a customer to later repudiate a previouslyauthorized transaction that could result in financial losses to the PostalService. Although it is not possible to completely protect against this risk (forexample, because of the possibility of credit card charge-backs andreversals), this risk can be considerably lessened through a properinformation audit trail.

If it is possible for customers to choose their authentication or securitymethod, they could elect to use a nonsecure or weak method that could allowan intruder to capture confidential information. For example, if the user wereallowed to choose the level of security for a session, the customer maychoose to employ an unencrypted session. If during that same session, thecustomer initiated a purchase using an off-line debit card, an intruder mightbe able to capture the customer’s PIN number which then provides both theaccess path and authentication information to complete a fraudulenttransaction of this type. The Postal Service could incur losses because oftransactions processed that were not actually authorized by the customer.

6-2.2 Reputational RiskReputational risk can perhaps be the most difficult type of risk to protectagainst because an organization’s reputation is largely a matter of publicopinion and history. The Postal Service must take steps to ensure that theimplementation of payment systems is completed in a manner that isconsistent with Postal Service policies and goals. In addition, with theemergence of the Internet as a global communications network, news ofsystem compromise, penetration, etc., can be spread quickly to a largenumber of potential or current customers. It is exponentially easier to lose a

6-2.3Risk Assessment Guidelines


large number of customers through negative publicity than it is to initially winthese customers; therefore, care must be taken to prevent incidents ofnegative publicity.

Reputational degradation can result from mistakes or malfeasance on thepart of the Postal Service or from malfeasance or fraud by a third party. Anadditional area of concern with the Internet that can affect reputation is therisk resulting from significant problems with communications networks, whichcan result in a degradation of, or even termination of, service to the customer.Substantial losses caused by mistakes of another institution offering thesame or similar services may cause Postal Service customers to viewofferings with suspicion even if the Postal Service did not experience a similarproblem. Finally, reputational risk may arise from targeted attacks, such asthose of a hacker penetrating the Web site and altering the page content.This can cause inaccurate, maligning, or obscene information disguised ascoming from the Postal Service that is presented to customers.

6-2.3 Legal RiskLegal risk arises from violations of, or nonconformance with, laws, rules,regulations, or prescribed practices or when the legal rights and obligations ofparties to a transaction are not well established. Given the relatively newnature of many retail electronic banking and electronic money activities,rights and obligations of parties to such transactions are, in many cases,uncertain. For example, application of consumer protection rules to electronicbanking and money activities may not be clear. In addition, legal risk mayarise from uncertainty about the validity of some agreements formed by wayof electronic media.

The Postal Service may also incur legal risk arising from the accidental orintentional disclosure of customer information or from a violation of privacyprotection regulations. Customers who have not been adequately informedabout their rights and obligations may bring suit against the Postal Service.Failure to provide adequate privacy protection may also subject the PostalService to litigation or prosecution under regulatory statutes.

If the Postal Service elected to provide additional flexibility to its customers bylinking its site to other Internet sites, the Postal Service could face legal risksarising from indirect fraud. For example, a hacker could use the linked site todefraud Postal Service customers, who may have recourse that would placeat least some liability upon the Postal Service.

Finally, as electronic commerce expands, the Postal Service may seek toplay a role in electronic authentication systems, such as those using digitalcertificates. The role of a centralized certificate authority may subject thePostal Service to a legal risk if it allows outside entities to rely upon thevalidity of its certificates for purposes not related to the Postal Service. Forexample, the Postal Service may be liable for financial losses incurred byparties relying on a certificate issued by the Postal Service that is fraudulentlypresented by an attacker. Legal risk may also arise if rights and obligationsare not clearly specified in contractual agreements between the PostalService and its customers.



6-3 Risk Analysis GuidelinesExhibit 6-3 describes the risk criteria and possible manifestation of risk, losspotential, and possible risk management. Some risks span risk categories.For example, a breach of security allowing unauthorized access to customerpayment or private billing information is classified as an operational risk;however, this event also exposes the Postal Service to reputational and legalrisks. Different risks arise from the same vulnerability, and the Postal Serviceshould consider all possible ramifications of security breaches whenevaluating electronic payment methods. The use of electronic paymentmethods over the Internet to obtain goods and services is currently in rapidexpansion. As new methods arise, the risks may change; this requires thePostal Service to continuously evaluate current and planned paymentmethods for suitability. Exhibit 6-3 should be used in conjunction withHandbook AS-805 during the development process to ensure that thepayment system is adequately evaluated during the development,implementation, and maintenance of the Postal Service Web application.



Exhibit 6-3 (p.1)Risk Guidelines

Risk CriteriaPossible Manifestationof Risk Loss Potential

Possible RiskManagement

Operational Risks

General Information Security

� Is payment systemconfigured to preventaccess by internal orexternal attackers?

� Internet hackeraccesses site:legitimate informationis replaced withhacker’s information;payment transactiondetails are copied,altered, deleted, orcreated; and theserver is shut down ordamaged.

� Disgruntled employeeaccesses paymentsystem computersand copies, alters,creates, or deletesinformation or causesphysical or softwaredamage to paymentsystem.

� Postal Service:Interruption ofdelivered services

� Postal Service:Delivery of goods orservices withoutpayment

� Use effectivephysical, procedural,software, andhardware controls foraccess to PostalService servers.

� Use firewalls, proxies,and routers to protectagainstnetwork-basedattacks.

� Use intrusiondetection and networkmonitoring of serversand networks fornetwork attacks.

� Implement stringentemployee hiringcontrols and performroutine monitoring ofemployee activitiesduring server andnetworkadministration andmaintenance.

Authentication

� What is theauthenticationmechanism?

� Who provides theauthentication?

� What is the renewalmechanism andperiod?

� Once authenticated,how manytransactions may beconducted withoutreauthentication?

� Use of stolen orillegitimate paymentinformation byhackers

� Illegal Postal ServiceWeb site posing asthe Postal Service,established to collectcustomer accountinformation

� Postal Service:Goods and servicesdelivered withoutpayment

� Customers: Failure toauthenticate thePostal Service servermay result in afraudulent PostalService host sitecollecting validpayment information

� Implement customerregistrationprocedures fortransactions.

� Use digitalcertificates,smartcards, or otherforms ofauthentication forhigh-valuetransactions.






Operational Risks (continued)

Unauthorized Access

� How does the systemprotect informationfrom unauthorizedaccess by external(e.g., Internet)threats?

� How is the systemprotected fromunauthorized accessby internal threats?

� Extracting or stealingcustomer paymentinformation by packetsniffing

� Alteration or theft oftransactioninformation whilestored on PostalService paymentsystem

� Customer:Fraudulent use ofcredit card

� Customer: Theft ofpersonal information

� Postal Service:Goods or servicesdelivered withoutpayment to the PostalService

� Postal Service:Damage to PostalService reputation,loss of public trust

� Use of encryption toensure that customerinformation isprotected fromsniffing networkattacks.


Payment Authorization

� Who performspaymentauthorization?

� How manytransactions may beperformed afterpayment isauthorized?

� How does the systemdetect attemptedfraudulent activity?

� Criminal use ofillegitimate paymentaccount numbers

� Misuse of system bylegitimate customersto defraud the PostalService


� Use paymentauthorizationcommensurate withthe transaction valueand frequency.

� Use velocity checksto identify possibleuse of stolen paymentinformation.

� Impose spendinglimits on customers.

� Implement softwaredesign that keepscustomers frommisusing the system.







Customer Privacy

Checkout phase:� What information is

collected?� What is the value of

the information?� Is the information

time-sensitive?Postpurchase phase:� What information is

stored about thecustomer after thetransaction iscompleted?

� Who has access tothe information?

� Inappropriatedisclosure ofcustomer transactionsor purchase history

� Customer: Loss ofprivacy; impact onpersonal credit history

� Postal Service:Damage to PostalService reputation;loss of public trust

� Use encryption toensure that customerinformation isprotected fromsniffing networkattacks.


Transaction

� What are theaverage, maximum,minimum, andmedian transactionvalues?

� How frequently is thepayment methodused?

� How is settlementaccomplished andwhen are fundsguaranteed?

� During each phase ofthe transaction, howis informationprotected?

� Can transactioninformation be copiedand used to performtransactions?

� Customer or criminalmisuse of the systemfor obtaining goodsand services becausetransaction controlsare inadequately setup


� Implement transactioncontrols for paymentmethod, dependingon transaction values,frequency of use, andsettlementprocedures.

� Use limits on dailyspending totals andrates of spending.

� Audit customerbehavior.







General Security Design

� How is the systemset up to preventabuse by belligerentor accidental actions?

� Can a customermisuse the system toobtain goods andservices withoutpayment?

� How are attacks ormisuse detected?

� How is use of thesystem monitored,logged, and audited?

� Web site maliciouslyhacked; informationdestroyed ordamaged

� Customer defeat ofcontrols (accidentallyor intentionally) toacquire goods orservices withoutpayment

� Postal Service: Lossof customer faith inthe ability of thePostal Service todeliver goods andservices

� Postal Service: Lossof customers


� Rigorously design,implement, and testhardware andsoftware.


� Use intrusiondetection to monitorE-commerce servers.

� Establish regularaudit procedures androutines to detectmisuse and networkattacks.

� Routinely self testnetwork forvulnerabilities.

Regulations, Laws, and Rules

� Can the systemcause the PostalService to becomelegally liable fornoncompliance withregulations, laws, orrules?

� Postal Service’sinadvertent violationof laws, regulations,or rules

� Postal Service:Fines, legal fees, andregulatory sanctions

� Determine legalrequirements forelectronic paymentsystems.

� Evaluate risktolerance for legaluncertainties.

� Review complianceperiodically.

� Obtain legalinterpretations fromregulatory authorities.






Legal Risks

Customer Disclosure Rights

� Does the systemprovide adequatedisclosure ofinformation tocustomers prior touse?

� Does the systemadequately explain tothe customer thelimits of liability priorto the customerproviding thatinformation?

� Customers notunderstanding theirrights, obligations,and the risks ofsubmitting paymentinformation

� Customers disputingthe resolution process

� Postal Service: Legalfees, loss ofcustomers

� Postal Service:Damage to PostalService reputation

� Postal Service: Lossof public trust

� Determine requireddisclosures forpayment method andensure that customerunderstands andagrees to them priorto using paymentmethod.

� Ensure that customerservice employeesare aware of typicaldifficulties thatcustomers may have.

� Evaluate costs andbenefits ofdisclosures beyondlegal minimum.

� Design anddisseminate productand paymentinformation to thepublic.

� Periodically reviewregulatoryrequirements.

Information Privacy

� Does the systemplace legal liability onthe Postal Service forinadequatelyprotecting privatecustomerinformation?

� Inappropriatedisclosure ofcustomer transactionsor purchase history

� Customer: Loss ofprivacy



� Use encryption toensure that customerinformation isprotected fromsniffing networkattacks.







Legal Risks (continued)

Money Laundering

� Can the system beused to launderfunds?

� Customers using thePostal Servicepayments system tolaunder money

� Postal Service: Legalactions for failure tocomply with knowyour customer laws



� Carefully implementcustomeridentification andscreening techniques.Use policies,procedures, andaudits to identify andreport suspiciousactivities.

� Establish price andvolume ceilings forcustomers, dependingon level ofauthentication.

Accounting

� What kind oftransaction tracking isdone?

� What is theinformationclassification?

� How is theinformation stored?

� How long is it stored?� What are the risks of

the retentionmethods?

� Failure to adequatelymaintain transactionrecords, causing thePostal Service toviolate accountingregulations

� Internal or externalparty accessingfinancial records andaltering, deleting, orstealing them

� Postal Service: Fine,regulatory sanctions

� Determine regulatoryand accountingrequirements forelectronic paymentsystems.

� Evaluate risktolerance forregulatory andaccountinguncertainties.

� Review complianceperiodically.

� Obtain interpretationsfrom accounting andregulatory authorities.

Appendix APayment Risk Checklist


Appendix A

Payment Risk Checklist

Instructions for Completing the Postal ServiceInternet Payment Risk Checklist

Using Exhibit 6.3, complete the following checklist to provide a security profileof the payment component of the Internet application.

A. Administrative1. Name of Application:

2. Checklist completed by:

3. Checklist reviewed by:

4. Date:

B. General Information

1. What forms of payment will be accepted?

Credit Card

PEPP Cache

ACH Debit

ACH Credit

Other (please specify)

2. How frequently is each payment method used?

Payment Method

Credit CardPEPP CacheACH DebitACH CreditOtherTotal

Expected Frequency of Use(percent, add to 100)

100%

3. Where will the payment function or server reside?

Fully within one of the Postal ServiceInformation Systems Service Centers (ISSCs)

At a vendor site

Appendix A Secure Internet Payment Policies


4. Do the product and/or payment functions require that any specialinformation about the customer be maintained?

Yes

Description of special information:

No

5. Value of the average transaction (see Exhibit 2-1.2, Checkout PhaseTransaction Values, to determine).

High

Medium

Low

C. Operational Security1. Describe general information security measures to be used to protect

against internal and external attacks (e.g., information replacement,copying, altering, or destruction; server shutdown; softwarecorruption); identify hardware, software, physical security, andpersonnel security measures:

2. For each area, describe the risk and the tool to be used to control orprevent the risk:

Risk Type Countermeasure

Authentication Authentication mechanism:

Who authenticates:

Renewal mechanism:

Renewal period:

Transaction limits:

UnauthorizedAccess

External threat protection:

Internal threat protection:

Appendix APayment Risk Checklist



PaymentAuthentication

Payment authorized by:

Maximum number of transactions after authorization:

Monitoring tools to detect fraud:

Privacy Protection of payment information at

Postpurchase:Checkout:

Access audit tool:

D. Reputational Risks1. For each of the following areas, describe the risk and the tool to be

used to control or prevent the risk:


General Unintended misuse:

Unintended purchase:

Intended misuse:

Intended purchase:

Detection tool:

Session audit tool:

E. Legal Risks1. Identify the laws, regulations, and Postal Service requirements that

apply to payment processes and information used by this Internetapplication:

Appendix A Secure Internet Payment Policies



Law andRegulation

Aspects of application that create legal liabilityfor the Postal Service:

2. For each of the following areas, describe the risk and the tool to beused to control or prevent the risk:

Customer Disclosure(Privacy)

Customer notices and warnings used:

Customer service awareness and responsescripts:

Level of risk (high, medium, low):

Collateral public information actions:

Information Privacy Type and extent of legal liability forunauthorized disclosure or misuse:

Money Laundering Accountability or audit trail of fundsmovement through payment system:

Price or volume ceilings by level ofauthentication:

Customer identification and screeningtechniques:

Appendix BAccounting Checklist


Appendix B

Accounting Checklist

Revenue Flow

1. How will products or services be classified?

AIC

GLA

PSFR

2. Does the product fit into existing codes, or will new codes need to beestablished?

3. Is the total sale considered revenue?

Yes (go to Question 5)

Existing codes

4. If no, when will revenue be recognized (i.e., when will the sale movefrom being recognized as a liability to being recognized as revenue)?

5. What portion of the sale is considered revenue?

6. Who will receive credit for the revenue?

Field office

Specific program. What finance number will be credited?

New codes

No

7. Who will be responsible for reconciling the revenue account?

Field office

Minneapolis ASC

St. Louis ASC

San Mateo ASC

8. Who will process invoices?

Minneapolis ASC

St. Louis ASC

San Mateo ASC

Appendix B Secure Internet Payment Policies


Payment Flow9. What forms of payment will be accepted?

Credit Card

PEPP Cache

Other (please specify)

10. How will Minneapolis ASC track funds received from settlement?

11. What kind of process will be available to reconcile with the informationcreated in the Web and database servers?

ACH Debit

ACH Credit

12. Who will absorb expenses?

13. How will revenue be reported?

Field office

Specific program. What finance number will be expensed?

How often?

In what format?

Refunds14. Will refunds be offered?

Yes

15. Who will authorize refunds?

16. How will refunds be tracked?

No

17. Who will absorb the expense?

18. Who will process refunds?

Field office

Specific program. What finance number will be expensed?

Appendix BAccounting Checklist


Cost19. Has a Finance number been set up to track costs?

20. Are accounting resources required?

21. Is equipment (hardward, software, etc.) needed?

22. Is training required?

No

Yes. Who will absorb the cost of training?

No

Yes. What finance number will be debited?

No

Yes. How many?

For what purpose?

Yes. What is the cost?

No

Customer23. Is the customer support center needed to support this initiative?

24. Where will it be located?

25. Who will be responsible for supporting customer service onpayment-related functions?

No

Yes. (go to question 24 and 25)

Appendix CAVS Matrix


Appendix C

AVS Matrix


CardholderAddressand GivenBilling AreCompared First Date

MasterCard Visa

AmericanExpress

Discover/Novus JCB

DinersClub

If TotalValue

is< $100

If TotalValue

is≥$100

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ActionCode

ActionCode


YY X Note 1 Note 1 Note 1 Note 2 Note 2


YY Y Y Y A Y Y Note 2 Note 2

Addressmatch, ZIPCodemismatch

YN A A A Y A A Note 2 Note 2

Addressmismatch,9-digitZIP+4 codematch

NY W Note 1 Note 1 Note 1 Note 2 Note 2

Addressmismatch,5-digit ZIPCodematch

NY Z Z Z Z Z Z Note 2 Note 2

Addressmismatch,ZIP Codemismatch

NN N N N N N N Note 2 Note 2

Cardnumber noton file

XX W Note 2 Note 2

Appendix C Secure Internet Payment Policies



If TotalValue

is≥$100

If TotalValue

is< $100

DinersClubJCB

Discover/Novus

AmericanExpressVisa

MasterCardFirst Date

CardholderAddressand GivenBilling AreCompared

ActionCode

ActionCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

ReturnedCode

Addressverificationunavailable

XX U U U U U U Note 2 Note 2

Retry orsystemunavailable

XX R R R R R Note 2 Note 2

Service notsupported

XX S S S S S Note 2 Note 2

Addressverificationnot allowedfor cardtype

XX E E E Note 2 Note 2

Addressverificationrequestedor notreceived

XX Note 2 Note 2

Notes:1. For Visa, American Express, and Discover/Novus the ZIP+4 is not applicable. Only the address and 5-digit ZIP

Code need to be sent for AVS.2. For the two columns on the right, the product manager must decide whether to accept or reject the credit

payment, using the following action codes:A = Accept Order; D = Decline Order; R = Retry Order Submission

Appendix DPayment Methods Matrix


Appendix D

Payment Methods Matrix

Appendix D

Paym

ent Methods M

atrix

Handbook F

-7, October 1999

117

Payment Methods MatrixCustomer United States Postal Service

Cost toSet up

Cost perTransaction Convenience

Cost toMaintain/Operate

Cost perTransaction

(Trx)FundsTiming

FundsCertainty

Value ofTransaction

AuthenticationLevel

WhenOperational atPostal Service

Credit – $0 ++ – % of TrxValue

Next Day ++ –, + AVS Today

DebitOnline

++ $0 – + – Next Day ++ –, + PIN 12–18 mo.

DebitOff-line

– $0 + – % of TrxValue

Next Day + –, + AVS Today W/AVS6–12 mo.)

PEPPCache

+ $0 + + – Prefunded ++ –, +, ++ User ID,Password

6–12 mo.

ACHDebit

– $0 + – – 2–4 Days + +, ++ Signature on file 6–12 mo.

ACHCredit

– – – – – 2–4 Days + +, ++ N/A 12–18 mo.

Fedwire + – + – – Next Day ++ ++ N/A TodayLockbox – $0 + – + Next Day + +,++ Signature on

checkToday

DigitalCash

– $0 + + – Next Day,Next Day +1

++ –,+ Vendordependent

??

E-Check + + + + – Next Day + +,++ Digital signature 12–18 mo.BIPS + $0 + – ?? Next Day – +,++ Digital signature 12–18 mo.Key: — low; + high; ++ very high

secure internet payment policies

Documents