2

© Payment Pathways, Inc. 2009


Description of Greenlist® — A Method for
Expediting Electronic Payments (July 2009)
Richard J. O’Brien, Jeff Morrow, Ralf Seiffe and David Farber
Abstract— Greenlist® is a new, patent pending business
method available only to banks to improve the authorization and
execution of time-sensitive asset transfers, primarily payments
but also transfers of confidential information assets such as
medical records or other sensitive securitized assets. The
Greenlist® is a directory service that verifies identities and
payment addresses before financial transactions are made or
before obtaining access to restricted information. In practice,
Banks query the Greenlist® to provide payors a means to locate,
validate and effect the instant transfer of assets. This reduces
transfer time and is accomplished without divulging the payee’s
confidential information.
Banks. the lowest cost risk bearers, maintain the Greenlist®
by becoming trusted registrars who assume the risk for identity-
related fraud based on the information contained within the
registry. This liability transfer substantially reduces the payor-
bank’s cost of bearing risks because they are left with only those
risks associated with payor authentication and authorization.
These risks are entirely in their own control.
Banks or third parties responsible for certifying that someone
or some entity claiming to be an authorized party is not an
impostor can now offer new levels of service at a substantially
lower cost for a variety of transactions. This enables assets to be
transferred irrevocably so ‘good funds’ can be credited instantly
upon receipt and essential parties can be immediately notified
that the asset transfer has been settled and with utmost
transparency.
Index Terms — Multistage interconnection networks, risk
abatement, transfer standards, ultra-large-scale integration,
expedited payments.
Greenlist® is a registered trademark of Payment Pathways, Inc.
I. INTRODUCTION
What is Greenlist®? It is both a directory of safe
payment addresses and a set of payment and billing
services that use that directory.
Richard J. O’Brien is with Payment Pathways, Inc., Chicago, IL USA
312-346-9400. robrien@paymentpathways.com.
Jeff Morrow is EVP at Dollar Bank in Pittsburgh, PA.
jmorrow842@dollarbank.com.
David Farber is professor of Computer Science and Public Policy in the
School of Computer Science at Carnegie Mellon University and in the Heinz
School of Public Policy, Pittsburgh, PA USA. Dave@farber.net
Ralf Seiffe is principal at Transmedial Communications, LLC, Skokie, IL,
USA. rseiffe@truthinaccounting.org
© Payment Pathways, Inc. 2009
3
A Greenlist® ID, or GLID, is SAFE because
debits will never be processed against a Greenlist®
ID without the owner’s prior approval. Only credits
and messages will be processed against a Greenlist®
ID without approval. Furthermore, all messages will
come from a bank and will not be spam or
marketing messages.
A GLID is SAFE because anyone sending money
to a Greenlist® ID is given some information
identifying the payee and providing a dispute
history about that payee.
A GLID is SAFE because information linking a
payee’s bank account to a GLID is never disclosed
to a payor.
A GLID is SAFE because it is coupled with a
matching Virtual Identifier (VID) to minimize
keying errors. (The VID can also act like a CVV.)
The Greenlist® services are bank-centric. To get
the full range of Greenlist® services, a Greenlist®
cardholder must be sponsored and registered by a
bank that has agreed to abide by the Greenlist®
rules. A more limited set of services is available to
self-registered individuals; entities that are not
natural persons cannot self-register.
The Greenlist® services are accessible through
either through a web-enabled mobile phone1 or
through the combination of a PC and phone, either
landline or mobile.
The Greenlist® services involve little
enhancement to existing bank payment
infrastructures.
1
A text-message-enabled phone will provide limited access to Greenlist
services.

The basic services supported are:
• Guaranteed small value payments, either
instant or next banking day, with immediate
electronic notification to the payee.
• Electronic bill presentment.
• “Instant” bill payment.
• An “unhackable” number for small-value
purchases online.
To keep things simple, we shall assume in
discussing the services that customers are bank-
registered customers.
A. X2X Guaranteed Small-Value Payments
This is a generalized GUARANTEED payment
service, a kind of electronic certified check with
instant electronic notification. It is for payments
involving small amounts because it imposes risk on
participating banks that is unacceptable for large
amounts. The sender can be a person or a small
business or organization. The receiver can be a
person or a business or organization of any size. It
is more than P2P. It covers P2P, P2B, B2P, and
B2B for small payments.
How does it work?
Using an access device and whatever security
process the bank has selected, the payor signs in to
the payor’s online banking site. Once signed in, the
payor uses the payee’s GLID and VID to authorize
payment to the payee. The payor can specify that
payment is to be immediate or next (banking) day.
The payor’s bank confirms with the Greenlist®
Directory that the GLID and VID match and obtains
from the Greenlist® Directory routing information
to make payment within the indicated time,2 public
2
This routing information will include a RT number or a BIN. It will not
include a true account number. It will instead include a pseudo-account
number that must be translated into a true account number at the bank
© Payment Pathways, Inc. 2009
4
information confirming the identity of the payee
(such as telephone number or, in the case of a
business, a name), and a dispute history. Depending
on whether the payor has sufficient funds and the
payor’s bank is content with the dispute history, the
payor’s bank decides whether to pay or not pay.
If the decision is to pay, the payor’s bank
provides to the payor the information identifying
the payee and the payee’s dispute history and asks
for confirmation to proceed with the payment. This
confirmation can occur either during the online
session or through a separate channel initiated by
the payor’s bank.
Once confirmation is received and the
payor’s account has been debited, what the payor’s
bank does next depends on whether payment is for
next banking day or for instant credit. If next day,
the payor’s bank originates an ACH credit for
settlement on the next banking day addressed to the
payee’s bank and sends an immediate electronic
notification of guaranteed payment to the payee’s
bank. If instant, the payor’s bank sends a credit
addressed to the payee’s bank through Pulse.
The payee’s bank in turn notifies the payee
electronically that payment has been guaranteed and
is either available immediately or on a particular
day, depending on what the payor specified.
B. Bill Presentment
Because a bank participating in Greenlist® can
determine through the Greenlist® directory what is
the bank of a Greenlist® cardholder, a participating
bank can send information, such as a bill, “care of”
the cardholder’s bank. The cardholder’s bank is
obligated to forward that information to the
cardholder.
So the Greenlist® services automatically permit
electronic bill presentment from any Greenlist-
registered biller to any Greenlist cardholder.
C. “Instant” Bill Payment
It is obvious that the X2X guaranteed payment
service completely addresses “instant” bill payment.
D. Un-hackable Internet Purchases
A Greenlist® customer receives a card
WITHOUT A MAGNETIC STRIPE that shows the
receiving the money. A sending bank will not get information about the
account numbers of customers of other banks.

customer’s VID and a special Internet purchasing
number, which conforms to the rules for a signature
debit card number. All requests for authorization
that purport to be card-present transactions will be
denied. If the number is used in a card-not-present
situation, the bank will not authorize for shipment
to an address other than the address on file at
Greenlist® or for amounts greater than a low dollar
amount.3 No authorization will be granted if the
customer’s phone number or email address differs
from those on file at Greenlist®. Whether or not the
bank authorizes the transaction, the bank will notify
the Greenlist® customer of the amount and
merchant who requested payment. The Greenlist®
customer will have a certain period of time in which
to authorize the payment.
If the payment is not authorized by the Greenlist®
customer within that time, the bank will first notify
the merchant that the authorization is invalid and if
the merchant insists on settlement, return it as an
unauthorized card-not-present transaction. No
money will be deducted from the Greenlist®
customer’s account unless authorization is received
from the customer even if the bank ends up having
to pay a merchant.
E. Self-registration
The key question is whether it is possible to
provide these services if only one bank is involved.
The answer is “yes.”
Any customer with a valid credit card can self-
register. Self-registration permits use of all
Greenlist® services except receiving instant
payments. Self-registration will involve some sort
of identifying system such as Verid. There will be a
small one-time fee to join. The fee will be over-
charged to the credit card as a card-not-present
transaction, and a credit will be made to the same
account for the amount of the over-charge. Before
registration is complete, the self-registrant must
specify the amount of the credit received. This
shows that the customer has access to the account
information for the card number provided. During
self-registration, the registrant also provides the RT
number and bank account number of the registrant
as well as phone and email information for
notifications.
3
If the customer wants to make a purchase that does not conform to these
limitations, the purchase must be pre-approved through a bank’s online site.
© Payment Pathways, Inc. 2009
5
Self-registered customers will be provided a login
id and a password for a special site hosted by the
Greenlist® bank.
A self-registered customer who wants to make a
payment goes to the special site and purchases an
electronic money order payable to any GLID. The
Greenlist® bank then transmits the money exactly as
it would for a regular Greenlist® payment and
collects using an ACH debit. If the ACH debit is
returned, the Greenlist® bank asks for an
authorization against the credit card, funds that way,
and charges the self-registered customer a penalty.
A self-registered customer can receive electronic
bills just as any other Greenlist customer can.
A self-registered customer can receive payments,
but not on an instant basis.
A self-registered customer can make un-hackable
internet purchases. To make them, the customer
must first come to the site for unregistered
customers and activate the internet purchase number
for a period not to exceed two hours by pre-
approving transactions for amounts (not to exceed a
customer designated limit) from certain types of
merchants.
II. GLOBAL VISION
What is the best predictor of a successful
financial transaction?
Since the first traders began exchanging their
possessions, the best predictor has been knowledge
of the identity of the other party. The size of a
transaction, the distance between traders, the nature
of the transaction, or even the languages of the
parties do not change the need to know the identity
of the other party to a transaction.
But the question, “who am I doing business
with?” does not always have an obvious answer. In
today’s fast paced, computer dependent world,
people make purchases, payments, deposits, and
other financial transactions without the exchange of
money, checks, or even the simple act of handing a
teller a credit or debit card. Many transactions made
by individuals today are done over the telephone
and Internet. Such a public forum requires security
measures, which are often tedious, inconvenient,
and can cause long delays in what are otherwise
simple transactions.

For both buyers and sellers, authentication of the
participating parties has become a high-value
assurance of security, the absence of which leads to
transactions risks and inefficiencies. Because
payees are reluctant to divulge their private account
numbers without the assurance of the safety, many
transactions continue to be made by cash or check
because payors cannot obtain the recipient’s
electronic payment address. For example, when
funds simply have to be transferred instantly to
another party, inefficient means are used such as
overnight delivery services, travel to a money-
transfer business, payment of check-cashing fees
upon receipt, etc.
Security is a major concern for online consumers,
too. Consumers shun utilizing pervasive networks
such as the Internet and mobile networks because
they worry that they might need to repudiate a
payment if goods or services are not received.
The Greenlist® business method can accelerate
the migration to pervasive electronic payment
systems by transferring the risks of providing
electronic payment addresses from payors to more
suitable registration entities. Banks can—and
should—validate the identity of counterparties and
mitigate concerns related to electronic transactions.
Using a priori information banks can supply data
pertaining to the counterparties’ histories of
completing transactions successfully.
But before banks can become arbiters of identity
and purveyors of transaction histories, they must
first build peer-respected capacity. The Greenlist®
Transfer Protocol (GTP) is a rule-set for banks to
construct, implement and maintain identity and
transactional information services via pervasive
© Payment Pathways, Inc. 2009
6
networking to expedite electronic payments
between individuals, between individuals and major
billers or between an individual and a merchant in
either an online or retail setting.
III. REGISTRARS
The following accreditation steps are necessary to
create Registrars with necessary permissions in the
Administration and Security Application to create
and maintain the Greenlist® registry. When such
steps are completed, registrars can certifiably enroll,
add, delete and edit registrants’ data in the registry.
A. Registrar accreditation
Organizations must be accredited to become a
registrar. The registry manages the accreditation
process based on a series of accreditation
requirements agreed with the Greenlist® Rules
Council. The council’s authority is created by
consensus of participating Greenlist® Pilot Banks.
It is comprised of representatives from banks and
participating payment network stakeholders.
To become a registrar, a bank must be in
compliance with its regulator’s requirements for
capitalization and remain in good standing in order
to continue functioning as a registrar. Registrar-
banks accept liability for any consequential
damages should its registrants’ data be proven
inaccurate. To expedite asset transfers, banks must
be certified as an Account-to-Account sender by at
least one debit network and agree to never debit any
ACH payment addresses retrieved from queries to
the Greenlist®.
Every registrant is issued a debit-blocked
Personal Account Number (PAN) that conforms to
INCITS/ISO/IEC 7812-1-2000 and 7812-2-2000.
Registrar-banks or their proxies must not put the
registry in breach of the laws on the protection of
personal information, or allow the registry to be put
in this position because of the registrar’s inaction.
B. Registrar responsibilities
Registrars’ agree it is important that a registrant
is fully informed and that they understand the
service levels and all relevant charges they should
expect. Registrars ensure that registrants are aware
of the charges associated with registration and

renewal. This includes giving details of the related
services provided which are relevant to the
customer.
The registrant needs to understand the terms of
their contract. Therefore, the registrar must make
registrants aware of the current version of their
Terms and Conditions before the Contract is made
and state how registrants will be made aware of
changes to the terms.
C. Registrar’s relationship with the registry
Greenlist® users must understand the relationship
between their registrar and the registry and
registrars should take the steps to properly inform
their customers and the public. To ensure all
registrars have a good understanding of the
technology and business processes involved in
registrations, a new registrar will be asked to
complete a course to demonstrate a basic
understanding of the Greenlist® registration and
maintenance process.
D. Proxy Registrars
Proxy registrar is the term used to broadly
define any non-bank institution that is duly
authorized by an accredited registrar-bank to enroll
a large number of users at one time. Examples
range from healthcare clearinghouses to mobile
network operators. Such institutions are now
addressing the emerging needs for Electronic
Remittance Advisory (ERA) payments. ERAs are
mandated for Medicaid and Medicare, and many
insurance carriers are implementing ERAs for all
payments. These payment communities all require
the ability to settle payments without today’s
security risks and payment delays.
E. Benefits of Proxy Registrars
The use of a Greenlist® eliminates the potential
risk of overdraft associated with Debit-ACH
transfers by issuing Credit transfers via one of
several payment networks, depending on the
payment application’s requirement. In addition to
the efficiencies associated with authentication
services provided by parties in the position to do so
with the least cost (e.g., banks), in the healthcare
context that use is augmented by subtler uses. One
is a reversal of the way that recurring billers are
© Payment Pathways, Inc. 2009
7
paid by putting control of payment release into the
hands of the consumer or small business. Certain
large billers may discover ways to incentivize their
customers to expedite payments on actual due dates
in order to lower interchange fees. Another is when
a small or even medium sized business is a health
care provider and the party billed is an insurance
carrier. Up to now, these entities have been
reluctant to provide their bank account information
to the carriers. Providers fear that payments, for
charges (that are later determined to NOT be
covered by an insurance policy) could be debited or
“clawed back” immediately, instead of being
reconciled in the next month’s payment cycle.
Banks, functioning as Greenlist® registrars, enroll
small businesses (such as health care providers) in
the Greenlist® and assess service fees. A portion of
this monthly fee is net income, and a portion of the
fee is used as net income for registrars to list debit
blocked (or debit filtered) payment addresses in the
public Greenlist®. In Healthcare, a Clearinghouse
through its Greenlist® registrar-bank, can serve the
Insurance Carriers by instituting a company to
function as a proxy registrar (for banks) and
perform Greenlist® enrollment functions by
obtaining a system use license.
F. Liability and Risk of Proxy-registrars
A registrar should be aware that if they operate a
proxy-registrar program, that registrar assumes
liability for the actions of its proxies.
The Contract makes the actions of proxies the
registrar’s responsibility so it becomes the
registrar’s responsibility to stop the proxy from
doing anything that would breach the registrar
agreement or accreditation requirements or to stop
them being one of its proxies.
In the event that a problem arises, registrars must
be properly reserved or insured. At minimum, the
registrar must provide evidence that the applicant
has appropriate professional indemnity insurance in
place. This should be cover of at least $500,000.
G. Notifications and Associated Responsibilities
All registrars are required to publish a code of
practice for complaint handling and dispute
resolution, including escalation plan and record

such events to the registry log.
The registrar must provide details of any relevant
litigation or regulatory enforcements e.g. details of
any regulatory fines, any outstanding court
judgments or details of any ongoing legal actions.
H. Batch Enrollments and the “Hold” Status
Minimally, to receive temporary “Hold” on
various identifiers such as GLIDs, Greenlist®
accepts batch registrations.
I. When to transition off “Hold” status
Proxy registrars submit batch enrollments.
Some examples are: Billing & Payment Service
Providers, Mobile Carriers, or a Healthcare
Clearinghouses. En masse registrations by proxies
are automatically put on “HOLD” status for thirty
days. This provides the customer sufficient time to
experience some limited application functionality
and learn more about the benefits of a fully certified
registration. When he authorizes a registrar-bank to
complete his registration, his enrollment is complete
and status becomes “Active” so instant payments
can arrive.
IV. PROCESS DESCRIPTION
A. Enrollment
This use case allows a bank customer to enroll in
Greenlist®. The customer submits the necessary
enrollment information via the bank application.
During enrollment the registrant can select a
Greenlist® ID (GLID) as his or her public payment
identifier. The registrar-bank’s online portal
application will then submit the enrollment request
to the GL Server. If the enrollment is successful, the
customer information will be stored in the database
and a Virtual Identifier (VID) will be created for
that registrant. If the update is not successful for any
reason, the API will return an error code and
description.
B. Manage Customer Information
This use case allows a bank application to update
GL Customer Data in real-time or via a batch
processing method. The bank customer submits the
necessary information updates via the bank
application. The bank application will submit
updates to the GL Server. If the update is
© Payment Pathways, Inc. 2009
8
successful, the customer information will be
updated on the master GL Database. An update
confirmation will be returned via the GL Server. If
the enrollment is not successful for any reason, the
API will return an error code and description.
C. Customer Look-up
This use case allows an authorized application to
look up a GL Customer in order to submit a
payment or a payment request. This lookup occurs
when the Payee does not belong to the same bank as
the Payor.
The Payor will enter a GLID to search for a GL
Customer. The Lookup API will return available
name and address data along with LCA-PAN of the
matching GL Customer.
Alternatively, Home Phone Number, Cell
Number or E-mail address can be used to search for
GL Customer. The API will return a reduced set of
information for non-banks, which can be used to
submit an invoice to the GL Customer. If the GL
Customer Lookup is not successful for any reason,
the API will return an error code and description.
D. Manage Customer Transaction Information
This use case allows the Greenlist® to record a
transaction involving the transfer of money from
Payor to Payee account. The bank application of
both the Payor and Payee will submit the
transaction to the GL Server, which will in turn
store the information about the transaction in the
Greenlist® Master Database.

E. Cancel Customer Registration
This use case allows a bank customer to cancel
their Greenlist® Registration. Once their registration
is cancelled, they will no longer be available for
Greenlist® lookups. The bank customer submits
their cancellation via the bank application.
The bank application will then submit the
cancellation request to the GL Server for validation.
If the validation is successful, the customer will be
cancelled in the Greenlist®. A cancellation
confirmation will be returned via the Bank’s GL-
enabled application to the customer. If the
cancellation is not successful for any reason, the
API will return an error code and description.
F. Manage Greenlist® Configuration
This use case allows authorized PPI personnel to
modify certain configurable aspects of the
Greenlist® system. This includes the length
requirements that apply to Greenlist® ID (GLID)
selection, the holding period for a GLID after GL
customer enrollment changes, and reserved GLIDs.
An administrative interface on the GL Server
provides this functionality. The user navigates to
the appropriate screen and the GL Server displays
the current values for all configurable items. The
user updates one or more of the configurable items,
submits the changes to the server, and the server
validates whether the new values are acceptable. If
validation succeeds, the updated values are stored in
the Master GL Database and the changes take effect
immediately for all subsequent API calls made to
Greenlist®. If the update to any of the configuration
parameters is not successful for any reason, the
system displays an error message.
G. Generate Pre-formatted Reports
This use case allows the Automated Report
Scheduler to generate pre-canned reports. All
reports will be distributed via e-mail to a pre-
specified e-mail list.
H. Generate Ad Hoc Reports
This use case allows authorized PPI personnel to
generate and distribute ad hoc reports.
© Payment Pathways, Inc. 2009
9
V. FUTURE PROCESS FUNCTIONALITIES
A. Transaction History Information
This use case allows a bank customer to obtain
information about previous transactions involving
the transfer of money to a Greenlisted payee that
agrees to make its history of successful settlements
as well as disputes available upon request.
B. Information Transfer Restrictions
This use case allows a bank customer to grant
access to its personal information only to entities
having certain credentials.
C. Information Transfer Notifications
This use case allows a bank customer to define
various cases for him to be notified when an
information transfer is sought. (notify and proceed,
notify to obtain separate permission, notify and
deny access, etc.)
VI. NEUTRAL PERVASIVE NETWORK POSITIONING
Without payment ubiquity, the network-effect
cannot snowball to achieve mass adoption. By
steadfastly encouraging every network and core
processor to support a common new component in
the payment ecosystem, merchants and consumers
alike will have multiple ways to learn about
Greenlist®. The first two Core Processors or Debit
networks to launch Greenlist® among its member
banks may negotiate a limited time period of
exclusivity prior to other Debit network activations.
Account-to-Account credit transfer transaction
services are in various stages of development at
Pulse (Discover Financial Services), NYCE
(Metavante, soon to be a division of Fidelity
National Information Systems (FNIS), Exchange
EFT (Fiserv), and STAR (First Data Corporation).
PULSE and NYCE are exploring how to gateway
incoming credits to Greenlisted payment addresses
between their networks.
All payment network stakeholders are affected
positively, as the volume of credit payments &
income increases without new capital expenditures.
VII. ENABLING NETWORK INTEROPERABILITY
PULSE and NYCE are exploring how to perform
gateway services for incoming credits to

Greenlisted addresses from each other’s network.
VIII. INITIAL PILOT APPLICATIONS
Two Debit networks and one core processor,
wishing to increase transaction volume and value,
will deploy Greenlist® in pilots beginning in
August, 2009 among four licensed bank registrars.
Each company strives to enable their bank and
credit union customers to earn new revenue by
selling instant payment services to as many
consumer and SMB accountholders as possible.
A flat rate of one nickel ($0.05 fee) is charged for
every query (a.k.a. lookup transaction) of one of
several Greenlisted identifiers to discover a
Greenlisted payment address to be used by the
payors’ bank to originate a payment.
Whenever an individual seeks to find or
authenticate any virtual addresses, they will trust
their bank’s Greenlist® to protect them.
IX. REGULATORY COMPLIANCE ISSUES
Greenlist’s open architecture enables search and
retrieval of trusted Identity information to achieve
interoperability between any payment systems. This
puts banks back into the center of the payment
process, generating revenue from registrations and
transactions. The thin nature of the directory and its
switch function adds a new factor of authentication
to safeguard bank payment transactions without
adding the burden of regulatory compliance.
Payment Pathways, during its sales process with
banks, accumulated insight into how banks have
responded to the Federal Financial Institutions
Examination Council (FFIEC) guidance. Each bank
that becomes licensed as a Greenlist® registrar
informs its regulatory agency and explains how the
Greenlist® factor adds value and supports the intent
of the FFIEC letter. By adding the Greenlist’s
identity verification factor for payees, any FFIEC
compliant system becomes the safest system
available today.
The design for Greenlist® has been vetted with
the Federal Reserve Bank of Atlanta, the Office of
the Comptroller of the Currency and the Office of
Thrift Supervision. We received positive responses
and regulatory guidance that was incorporated in
© Payment Pathways, Inc. 2009
10
the design and implementation process. Dialogues
with state and federal regulatory bodies continue.
The Federal Reserve Bank of Atlanta has
announced an ongoing study to learn how to
implement intra-day settlement with the ACH. The
Electronic Payment Network is working on an
Account-to-Account transfer system that would
utilize identifiers that are eligible to be Greenlisted.
We interpret these signs as proof that the banking
industry is prepared to rally around the leadership of
the Greenlist® consortium banks. Another industry
signal is the American Bankers Association
convened an Interchange Task Force to tackle fraud.
X. CONCLUSION
Banks recognize their fates are inextricably linked
together. They agree that building a ‘commons’
infrastructure for use by all transacting parties is the
best way to grow Non-interest income (NII) while
achieving new economically meaningful levels of
service.
X. ACKNOWLEDGMENT
The authors acknowledge the support of Dollar
Bank, Pittsburgh, PA and Zenith Information
Systems, Inc. of Los Angeles, CA.
AUTHORS
Richard J. O’Brien B.A. McGill University (1976)
Mr. O’Brien is the co-inventor of the Greenlist® Transfer Protocol. He
currently is the President and CEO of Payment Pathways, Inc. in Chicago,
IL, USA, a company he founded in 2003 to commercialize the GTP.
Jeff Morrow B.A. Columbia University (1966); M.B.A. Wharton School of
Finance (1972).
Mr. Morrow is the Executive Vice President of Dollar Bank F.S.B. of
Pittsburgh, PA. Mr. Morrow has direct responsibility for Branch
Administration and Services, Data Processing, Operations, and Community
Affairs and Development, in addition to Planning and Marketing.
David J. Farber B.S.E.E. Stevens Institute of Technology (1956) Doctor of
Engineering, hon., Stevens Institute of Technology (1999)
Prof. Farber is Distinguished Career Professor of Computer Science and
Public Policy in the School of Computer Science at Carnegie Mellon
University holding secondary appointments in the Heinz School of Public
Policy and the Engineering Public Policy Group. Dave sits on the FCC’s
Technological Advisory Council and Advisory Council of the CISE
Directorate of the National Science Foundation. He is a Fellow of the
Electronic Frontier Foundation and the IEEE.
Ralf Seiffe Bachelor of Business Administration, University of Wisconsin,
Madison, WI, USA ’76 Principal at Transmedial Communications, LLC and
co-founder of the Institute for Truth in Accounting, Northbrook, IL, USA.