Seller Registration and Verification 3YAP Appendix

1 APPENDIX 1: SELLER REGISTRATION AND VERIFICATION TENETS (UNLESS YOU KNOW BETTER ONES…) .............................. 1
2 APPENDIX 2: TERMINOLOGY ................................................................................................................................................. 1
3 APPENDIX 3: HOTLY DEBATED TOPICS .................................................................................................................................. 2
4 APPENDIX 4: THE 3YP ............................................................................................................................................................ 2
5 APPENDIX 5: FREQUENTLY ASKED QUESTIONS ..................................................................................................................... 4
6 APPENDIX 6: 2020 EOE .......................................................................................................................................................... 5
7 APPENDIX 7: 2018/2019 HITS AND MISSES ........................................................................................................................... 6
8 APPENDIX 8: CURRENT ARCHITECTURE ................................................................................................................................. 7

9 Appendix 1: Seller registration and verification tenets (Unless you know better ones…)
10 1. Buyers and sellers are our customers. When forced to prioritize, we prioritize protecting buyers over reducing seller friction.
11 2. We do not conduct business with anonymous or pseudonymous entities. We verify that the sellers are who they say they are, that
12 their businesses are located where they say it is, and that the Sellers own their payment instruments.
13 3. Verified Seller information is global. We do not re-verify a Seller’s identity when they choose to expand to a new marketplace.
14 4. Verified Seller information is non-static. We monitor changes in seller information throughout the lifecycle with Amazon and re-verify
15 the information when required.
16 5. We believe that setting a high bar for identity verification is not correlated with increasing Seller friction. We provide a great Seller
17 experience through high accuracy of decisions, clarity in communication, timely help, and by consistently meeting our decision time
18 promise.
19 6. We automate decisions when the accuracy of the decision is equal to or better than a manual decision.
20 7. We are transparent and precise in the information Sellers need to provide, but do not share how we make our decisions. When we
21 communicate with Sellers, they are able to answer: (a) why we require certain information, (b) what we do with it, and (c) what are the
22 benefits of providing the information.
23
24 Appendix 2: Terminology
25 Online identity - Online identity is an identity that is used for transacting digitally. Email address, domain names, phone numbers, etc. are
26 examples of this. Online identity is also called online personas and does not connect back to a real person.
27 Recognized identity - Recognized identity is an identity issued by a recognized body through a process that has established physical contact
28 with the person to whom the identity was issued. For example, in most countries, issuance of a passport requires going to passport office
29 to provide biometrics. Passport is an example of recognized identity. Recognized identity is also referred to as physically verified identity.
30 Identity source – A source of identity. Identity source can be online identity source or recognized identity source.
31 Identity enrollment - The process of collecting identity attributes and issuing identity credentials. Enrollment answers “Who are you?”.
32 Identity credential - A mechanism, process, device or document that vouches for the identity of a person through some method of trust.
33 Identity validation – Identity validation is the process of proving your identity using the identity credentials. Validation using identity
34 credentials answers “Are you who you claim to be?”.
35 Identity establishment - The main responsibility of “Identity establishment” is to associate online identity to recognized identity. An
36 example of this is associating the amazon customer (online identity) to corresponding passport (recognized identity) using identity
37 validation techniques like in-person verification. This allows us to answer the question “Is the Amazon customer who he claims to be?”.
38 Identity assurance score – A score indicating the level of certainty that credential representing an entity belong to the entity. Identity
39 assurance score is provided as an output of identity validation by each identity source.
40 Identity association confidence – A measure of our confidence in the association process. This is the output of the identity establishment
41 process. This is computed using the individual identity assurance scores of the various identity sources that were used during the
42 association.
43 Digital identity provider - A digital identity is a collection of electronically captured and stored identity attributes that uniquely describe
44 a person or business within a given context and are used for electronic transactions. A digital identity provider refers to the systems and
45 processes that manage the lifecycle of individual digital identities. Digital identity providers perform enrollment through physical
46 verification, issue digital credentials and expose mechanisms for identity validation.
47 National digital identity systems - A government-supplied national digital identity provider. These systems provide digital identities based
48 on identity attributes defined by national law.
49 Headless - Headless refers to part of the implementation that is independent of the presentation (user interface). In Mario’s context,
50 headless refers to widget’s service APIs that are agnostic of the format and platform on which the data is collected.

Amazon Confidential 1 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
51 IPC - IPC is an acronym for Identity establishment, Product eligibility and Compliance validation. These are the main steps that make up
52 verification.
53 RepSer - Replication Service (RepSer) allows teams to reliably and securely replicate data across regions. This is required as most of the
54 downstream services today are deployed regionally. For global registration, in order to make the data collected in one region, available
55 globally, RepSer triggers a workflow to fetch data from source region and persist in target region.
56
57 Appendix 3: Hotly debated topics
58 Appendix 2, Terminology, is a suggested pre-read. Here are our hotly debated areas.
59
60 1. Should we become a digital identity provider?
61 The current charter of Identity establishment is to associate the online identity to recognized identity. This is sufficient to meet our
62 business need and threats for today. However, this may not protect us from newer threats and we have an opportunity to raise the bar
63 by evolving into a digital identity provider. Currently, as a part of identity establishment, we collect identity attributes from various sources
64 and match them. By doing this, we are building a high-quality internal identity attribute store. Should we evolve to become a digital
65 identity provider? This requires us to perform enrollment and involves collecting biometrics (may lead to PR backlash). We can do this by
66 repurposing our in-person validation system to start collecting identity attributes (like fingerprints, face, iris scan, etc.) instead of
67 credentials. As a digital identity provider, we are the source of truth and no longer have to rely on other sources like passports, etc. There
68 are two parts to this hotly debated question. First, should we evolve to become a digital identity provider? Second, should we vend out
69 the digital identity that we have collected to other systems?
70
71 2. Should we provide a special purpose device to in-person verification associates?
72 The task of in-person verification associates is to perform validation of the physical credentials. A typical task of such an associate would
73 be to examine customer’s physical credentials like the original passport and match that to the face. The physical credentials are scanned
74 and uploaded to Amazon systems. Associates need to use a device to capture the picture of the passport. A mobile device with our
75 application is a good starting point. However, by doing this we still rely on the associate’s judgement to perform forgery detection of the
76 originals. Should we provide a special device (or attachment to a mobile device) to these associates that help detect forgery or capture
77 biometrics? The possible options are simple attachment to capture fingerprint to a more complex device that emits blue light to illuminate
78 specific regions of a document. A possible option is equipping only some associates for validation of high-risk customers. The other option
79 would be to setup booths with this capability and asking high-risk customers to visit them.
80
81 We believe we should do both “1” and “2”.
82
83 Appendix 4: The 3YP
84 Table 1: Data Collection 3-year plan
# Component Current state 2020 2021 2022
1 Type: Platform Our current registration 1. Provide Proxy Widget to 1. Remove support for 1. Deprecate
Name: SWIPE platform that powers all allow deploying existing SWIPE SWIPE and move to by removing
Description: The regional registrations, pipeline on Mario. community support mode. SWIPE
current registration global registration and 2. Clients to switch Proxy packages.
platform on the account settings. Clients Widgets to Mario widgets
path to include Brand Registry, transparently.
deprecation. VISA, Amazon Pay, etc. 3. SWIPE platform to be on KLO
to support our existing clients.
2 Type: Platform The current version of 1. Support for Single Page 1. Support for dynamic data 1. Add
Name: Mario Mario supports global Applications (SPA). collection scope. This is conversatio
Description: flows for the SOA sellers. 2. Flow orchestrator to support required to globalize nal UI
Implementation of Mario also integrates iterative data recollection for account settings, where a support for
the data collection with RepSer to provide supporting gradual user might choose update a widgets.
architecture. replication support for all enforcements. setting in one or more
regional widgets. Mario 3. Supports Mario widgets on regions.
also provides Proxy Mobile app and Nautilus. 2. Enable onboarding of
widgets to migrate 4. Add accessibility support to Intergalactic clients on
existing SWIPE fragments widgets. RepSer.
to widgets. 3. Support newer clients on
Mario like Brand Registry,
etc.
3 Type: Application We currently have 16 1. Support EU sellers on the 1. Move Account settings to 1. Launch
regional registrations on current GREX platform. Mario. Global

Amazon Confidential 2 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
Name: Regional SWIPERTOL, 1 2. Move current Account
pipelines registration on India implementation GREX to Mario Settings.
(SWIPERTOL), stack and a global using Proxy Widgets.
Global Registration registration on GREX. 3. Launch the new global
(GREX) and Account registration experience Orbis
settings on Mario - MARIOGREX.
Description: All 4. Deprecate all regional
stages of registration pipelines and
registrations redirect sellers to MARIOGREX.
4 Type: Application There is no such feature 1. Build Seller expansion 1. Add experience to allow 1. Support
Name: Seller available today. system to enable existing SOA recollection of expire/stale expansion
Expansion Expansion happens sellers to expand across data. across
Description: Allows manually through scripts. geographies by only providing 2. Support expansion to Amazon
existing sellers to delta information. This requires India registration flow. products like
expand to any all registration flows to be Amazon Pay,
marketplace developed on Mario. Home
worldwide. services, etc.
85
86 Table 2: Verification 3-year plan
# Component Current state 2020 2021 2022
1 Type: Platform Our current platform that 1. Stop all new onboarding to 1. Deprecate RAMP and CP. 1. RAMP and
Name: RAMP, CP powers identity RAMP systems. CP retired.
and Checkpoint verification compliance 2. Migrate SOA to IPC by
Description: Our and the product specific moving out of RAMP, CP and
current identity rules for Amazon Pay, Checkpoint.
verification, Mechanical Turk, AWS 3. MTurk to migrate out on
compliance and Marketplace and Selling their own.
product platform on Amazon.
2 Type: Application PE review with aravindy@ 1. Build Person, Business and 1. Integrate with digital 1. Expose
Name: Identity and dons@ to be done by Payment widgets. Build the credential validation Identity
establishment 15-Nov. following credential validation systems like Aadhaar, NDI, establishment
Description: This is systems “In person etc. as an AWS
the “I” of the IPC. verification”, “video chat”, 2. Expose association levels offering.
“Post card verification”, “bank as a score.
account login” and “manual 3. Allow business outside
review”. SOA to use Identity
2. Build a new Identity Store establishment.
and integrate RAMP data as
another identity attribute
collection store.
3. Enable SOA and AWS MP to
use Identity establishment.
3 Type: Application Requirements and design 1. Build support for SOA 1. Allow business outside 1. Expose
Name: Product closure by 1-Nov-19. product eligibility. Integrate SOA and AWS MP to use Product
eligibility with URES and RAE for risk Product eligibility by eligibility as
Description: This is calculation. Enable queuing defining and hosting their an AWS
the “P” of the IPC. support based on the risk. own eligibility logic. offering.
Build AWS MP product
eligibility.
2. Build Behavior Analysis
system for analyzing users key
stores, mouse movements and
anomalous surge patterns
3. Build CoC, Periodic
verification and secondary
user verification flows
worldwide.

Amazon Confidential 3 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
4 Type: Application Requirements and design 1. Build compliance validation 1. Expose
Name: Compliance closure by 1-Nov-19. system for SOA and AWS MP Compliance
validation businesses. validation as
Description: This is 2. Build final overview on our an AWS
the “I” of the IPC. “manual review” system to offering.
enable moving out of CP and
Checkpoint.
87
88
89 Appendix 5: Frequently Asked Questions
90 1. How is the verification landscape evolving for us?
91 A. Rapidly evolving bad actor MOs requires us to be nimble in building defenses – Adding friction at registration for bad actors also
92 affects the good actors. Bad actors are well versed with our registration process and finish registration quicker than good actors. Reacting
93 to surges is extremely time consuming (weeks to months).
94 B. Bad actors exploiting differences in regional stacks and lack of continuous monitoring of identity changes - We do not verify
95 information after registration (in non-EU Marketplaces) allowing bad actors to falsify their address, or takeover accounts. While we have
96 Change of Circumstance (CoC) and Periodic KYC in EU, it does not prevent bad actors from changing their business address that is displayed
97 on Seller Central post-registration. We allow verified information to go stale by not having a mechanism to re-verify information through
98 the Seller lifecycle.
99 C. New tax regulations and compliance requirements slows us down – We self-fund high priority compliance projects which requires
100 significant technical investments at our end. At the end of Q2 2019, we received requirements to comply with Japan’s Installment Sales
101 Act (JP ISA). This required 3.5 SDEs for the rest of the year and forced us to deprioritize key initiatives on our roadmap. Our architecture
102 does not have the necessary flexibility to incrementally build support for such requirements or allow other teams to build features as an
103 away team.
104
105 2. What services that you own can/are used outside your organization/CTPS?
106 A. Alexandria – A Tier-1 InfoSec certified custodian service to hold user critical information (UCI) and critical classified documents, images,
107 audio and video in Amazon (more than 148 clients, more than 36B+ docs). Alexandria is integrated both in the order and fulfillment
108 pipeline.
109 B. Cairo – ID Document automation service that is currently in use for SOA. However, multiple clients including Amazon Pay India, Prime,
110 AWS, VISA are in different stages of OP1 discussions to integrate with Cairo for their document processing use cases. AWS Textract and
111 Rekognition teams are interested in collaborating with us to make Cairo an external AWS service and currently a joint PRFAQ with the
112 AWS Computer Vision Product team is in progress.
113
114 3. What services are you deprecating next year?
Service What does this service do? Why is this being deprecated? Benefits? Replacement?
SCORE This service acts as a backend This is a 7-year-old service that Deprecating this service will The KYC related API
Service for Account Settings and KYC has about 180 APIs and reduce tech debt as this will be supported by
data store. significant portion of them are service is using 15+ ODS. Account
unused. About 60% of the code deprecated packages. settings team is
is dead code. KYC related data planning to build an
has been moved to RAMP ODS alternate service to
and hence this functionality is support their
also not required. functionality.
SKIES This service was backend for As part of the LRI project, we Not deprecating. We are SIVISService is used
Service EU registration and KYC. have migrated from APAS to transferring ownership to as the backend now
RAMP and hence this service is Amazon pay team. for both NA and EU.
not being used for SOA use case.
Amazon Pay is still using this
service as part of their
registration. We plan to transfer
ownership of this service to
them instead of deprecating.
Alexandri This is the original architecture Migrating to Cells would result IMR savings around 600K Cells Architecture.
a of Alexandria. Our goal is to in simplification and IMR cost every year after migration for
Legacy migrate all existing clients to reduction the next 5 years (overall 3M$).
Alexandria Cells.

Amazon Confidential 4 October 15, 2019

 Seller Registration and Verification 3YAP Appendix

Issuance Mturk business use We have observed the amount IMR cost reduction of 200K N/A
Platform AmazonPayments accounts spent on retail checkout is on an annually
for managing earnings for average 5.5% of the total Savings for 1.5 SDE on
MTurk workers. Amazon earnings which amounts to Operational support for IPL
Payment accounts are open approx. $150K per month for Simplified
loop stored value accounts approx. 10K onboarding/reduced friction
(SVA) managed by IPL where transactions/purchases(Data for MTurk workers.
customers can either use their averaged over last one year).
funds to buy on amazon or
disburse them directly to their
bank account.
115
116 4. What L6 AND L7 SDE scope projects do you have in the next three years?
117 A. RAMP simplification – Segregation of RAMP into the Identity establishment, Product eligibility and Compliance validation.
118 B. SWIPE simplification – Creating a hosted service (Mario) which leverages remote federated data collection widgets and provides out
119 of box data globalization and facility for plugging in various presentation heads.
120 C. Launch of Orbis on Mario – Replacing multiple regional and product registration pipelines to a single pipeline, Expansion of existing
121 Sellers to other marketplaces and Globalization of account settings,
122 D. Cairo as an AWS Service.
123 E. Forgery Detection Techniques – Font-based forgery detection, Counterfeit detection, Unsupervised Learning of forged document,
124 Synthetic Data generation, etc.
125 F. Alexandria as an AWS service will require major enhancements in Alexandria’s code base as we will focus on improving our fault
126 tolerance, customer isolation, automatic Cells provisioning, heat management etc. which will be a PE scope project.
127 G. Sanitization as a service is a SDE 3 scoped project.
128 H. Extending Alexandria to support Payment Instrument Data Handling Standard will be another SDE 3 scoped project.
129
130 5. What is different across KYC and SIV?
Verification SIV in NA KYC in EU
Documents ID and Address Verification Documents ID and Address Verification
ID 1. Passport 1. Match name on ID Proof 1. Passport 1. Match name on ID Proof
2. Driving License 2. Match Date of birth on ID 2. Driving License 2. Match Date of birth on ID Proof
Proof 3. National ID 3. Validity of ID Proof
3. Validity of ID Proof 4. Match ID Proof
5. Expiration date
6. Match ID Proof Place of birth
7. Match ID Proof ID Number
Address 1. Bank statement 1. Match address on ID 1. Utility Bill 1. Match address on utility bill
2. Credit card Proof 2. Address Proof validity and legitimacy
statement 2. Credit card/bank 3. Utility bill expiration check
statement ownership check
Bank N/A N/A 1. Bank Statement 1. Bank Statement ownership check
Account
131
132
133 Appendix 6: 2020 EOE
134 Table 10: 2020 EOE projects

Amazon Confidential 5 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
Project Feature List
1 SCORE Service Deprecation ​SCORE Service is a legacy service used for registration and KYC. Since we built ScoreRGP service, the registration related code in SCORE is
unused (>60% of code). After migration of Score DB to ODS, the KYC portion is not required.
2 Regional SIV Pipeline Deprecation ​Once all NA and EU traffic is migrated to GREX, deprecate NA SIV and EU domestic pipelines.
3 Zero touch customer onboarding and integration ​We will automate all manual touch points in Admin Portal to make it fully self-serve.
4 Deprecate Issuance Platform Mturk is the only customer that is planning to close SVA feature. Migrate current payments details to alternate system.
5 Deprecate investigator use of console RAMP console is an internal developer debugging tool, but is used by investigatiors creating an audit risk. These use cases will be migrated to
Calypso.
6 APAS deprecation Deprecated legacy SIV system – APAS. Mturk and APAY are two clients
7 Alexandria 100% Migration to existing Cells system (ATL) We will migrate all existing non cells workloads (2% of existing traffic) to Cells and deprecate DDB tables for existing documents.
8 Minimize the Secure room dependency for SDE/AS Today, SDEs test their code against the dataset (red data) in a secure room which leads to security issues and slows speed of execution. To
address this we will reduce the dependency on the secure room, and allow SDEs to do regression testing of un-reviewed changes remotely and
in a distributed manner without giving them direct access to the dataset.
9 Reduce incoming ticket count in Account Settings. In 2018, the incoming tickets count was 18,283. As per the current projection the incoming count will be 17,940 (ramp of 345 tickets per week)
in 2019. This translates to 5[1] tickets per day per SDE. This is not a sustainable operation load on the team. The goal is to bring down incoming
to 1 ticket per day per SDE. (3,285 tickets, reduction of 80%). This will be achieved by fixing 81 root causes investigated by team. 20 root causes
will be fixed in 2019 and 61 will be fixed in 2020.
10 Self Service onboarding to Aurora Aurora is used to bootstrap downstream systems at the time of registration launch. A new service/system should be able to onboard
themselves in Aurora in a self service fashion.
11 CYM tool enhancements. Currently CYM(Create Your Merchant) and MCT(Merchant Classification tool) are two tools used to create internal merchants. Both tools have
inconsistent ways to mark a merchant as internal which creates issues during enforcements. We will also enhance CYM tool to onboard launch
135 of new products, marketplaces seamlessly by extensive documentation and granular error messages.

136
137 2020 EOE Goals
138 1. Reduce the number of resolved/closed high-severity tickets (minimum severity 1 – 2) from X to Y, a 10% YoY reduction from 2019.
139 2. Reduce the number of resolved/closed low-severity tickets (minimum severity 3 – 5) from X to Y, a 10% YoY reduction from 2019.
140 3. Close 90% of Critical and High Anvil risks for application deployed to production within SLA every month.
141 4. Increase the percentage of automated deployments from X% on 12/31/2019 to Y% by 12/31/2020, and maintain/improve thereafter.
142 5. Improve IMR Credit Score (on a scale of 1 to 100) to X by 9/30/2020.
143 6. Grow CTPS fleet annual IMR by no more than $XMM, from $YMM in 2019 to $ZMM in 2020, an increase of A% YoY.
144 7. Deprecate all regional pipelines by 12/31/2020.
145 8. Deprecate IPL system by 12/31/2020 to save $300K / year and reduce 500 tickets / year.
146
147 Appendix 7: 2018/2019 Hits and Misses
148 A. Hits
149 1. Migration of 95% of Alexandria traffic (Beejak) to Cells architecture resulting in yearly IMR savings of 1.1M$1.
150 2. Cairo MLP launched as Native AWS service using Workflow Symphony.
151 3. Auto-decisioning of ID Documents is at 58% WW as of week 37.
152 4. LRI launch - On 4/19 we launched a new SIV/KYC experience for sellers in EU. This launch included UX improvements over previous
153 pipeline along with the migration to RAMP as the platform for Identity Verification from the legacy APAS based system.
154 5. Call me Now: On 8/1 we launched "Call me Now" functionality as a limited pilot for sellers that are in RFI/RFD in EU. This allows sellers
155 to schedule a call with a TRMS associate to get help if they are stuck in RFI/RFD.
156 6. SX Improvement based on OCR: On 5/28 we launched field level suggestions for Sellers based on Cairo OCR data. This helps sellers in
157 correcting errors while submitting information thereby reducing the number of RAD cycles.
158 7. UTF8 Name collection for CN and JP sellers: We now collect POC Name / Legal Business Name of sellers in Chinese and Japanese in
159 additional to English based on their Country of Establishment. This helps in improving automation of document verification for these
160 sellers.
161 8. Sole Prop in EU7 & CN - On 8/14 we launched "Sole Proprietor" as a business type in EU for sellers whose country of establishment is
162 EU7 or CN.
163 9. Score to RAMP data migration: We successfully migrated 99.9% (~1500 sellers pending) seller data from Score to RAMP data store.
164 This involved scaling RAMP services, handle legacy seller data discrepancy challenges and seamlessly migrating the in progress seller
165 workflows to RAMP.
166 10. Duplicate Accounts detection: We built an Elastic search-based service that will enable us to query seller identity attribute to identify
167 patterns of duplicate values across seller accounts and take enforcements at registration time. The first launch will check of duplicate
168 ID# (passport, SSN, National ID etc.) across seller accounts.
169 11. RAMP simplification and deployment time improvements: RAMP has 20 services that followed a single monthly deployment cadence
170 with cost of 13 days of SDE effort and 1-2 weeks of calendar time. In 2019, we invested in configuration management tooling, test
171 automation and service simplification that has enabled each service to perform independent biweekly service deployment and
172 reduced cost of deployment from 13 days to 7 days. Increased the number of services in Mostly CD from zero to 7 in Sep 2019.
173 12. IMR and credit score. Hardware optimization has reduced annual IMR cost from 1.09MM in 2018 to $700K (projected) in 2019. RAMP
174 v1 credit score improved from ~30 till July to 55 in Sep and v2 credit score improved from 19 in July to 40 in Aug.
175 13. Registration launched in UAE with SIV V2.
176 14. Launch of EU MFA before hard deadline of 9/14.

1 Cost summation of YoY DDB IOPS, storage costs growth and reduction in existing IOPS due to migration of 95% traffic.
Amazon Confidential 6 October 15, 2019
 Seller Registration and Verification 3YAP Appendix
177 B. Misses
178 1. Incomplete initiatives due to priority changes: We invested in initiatives and projects (Login BAV, Auto BIV, Auto IDV, Micro deposits)
179 that were deprioritized after spending multiple weeks/months of investment leading to lost effort and employee morale.
180 2. Delay in Rainier Deprecation: We missed the deadline of 4/30 to deprecate the KYC Rainier pages in Seller Central as we failed to
181 identify that Amazon Pay is still using our application. We are working with Amazon Pay to rebuild these pages in Mons. These new
182 pages will go live on 11/7 and our new ETA to deprecate Rainier stack is 11/30.
183 3. IVX is red on high severity and low severity goals. YTD, we have 77 high sev tickets against a goal of (revised target of 103). YTD, we
184 have 1434 low sev tickets against a goal of (revised target of 1945). Biggest drivers have been non-intuitive UX leading to customer
185 confusion, downstream dependency service issues and SOP issues. In August we launched a fix for the Bad Document upload UX and
186 since then we have seen reduction in overall TTs (250 in Jul vs 167 in Aug). We have also taken the following actions: (1) Fixed an issue
187 related to address deletion. (2) We are working on SOP updates related to COE/COI support which will help us reduce further tickets.
188 (3) We are looking at Amazon Diagnostics, a tool used by SeSu to find opportunity to improve SIV/KYC related questions so some of the
189 tickets can be directly assigned to relevant teams instead of IVX and working with the SeSu Ops excellence team to optimize further to
190 reduce our incoming volume.
191 4. RAMP is red on high and low sev tickets: RAMP missed both high and low severity ticket reduction goals (1956 low severity TTs until
192 9/18 vs an expected ramp of 1303 and 334 high severity TTs until 9/18 vs an expected ramp of 233). Primary drivers are aggressive and
193 duplicate alarms, code bugs and SOP gaps. We are prioritizing automated test coverage and detailed alarms reviews in Q4. De
194 5. Delay in 100% dial up of Global Registration in NA (we are at 50% currently).
195
196 Appendix 8: Current architecture
197 A. Registrations Architecture
NA Registration Pipeline EU Registration Pipeline FE Registration Pipeline
Regional Registrations
Address Address Address Address Address Address [Stack: SWIPERTOL] {One for each region}
Fragment Fragment Fragment Fragment Fragment Fragment

Name CC Name CC Name CC Global Registrations pilot

Fragment Fragment Fragment Fragment Fragment Fragment [Stack:GREX] {NA}

Page 1 Page 2 Page 2 Page 1 Page 2

Ownership Account Settings
Fragment
[Stack: MACSWIPE]
Page 1

Figure 1: Registration pipeline on SWIPE Figure 2: Registration stacks

198
199 Seller registration is fragmented by marketplaces today. There is a different registration experience for each marketplace we operate in.
200 There is very little data sharing between these regional registration experiences. As a result, Sellers have to provide the same information
201 again, as they expand to new regions. In January 2019, we launched Global registration (GREX). This was a pilot which allowed sellers to
202 simultaneously register in NA, EU and JP marketplaces. As part of the pilot, (1) we rationalized common data elements which did not have
203 dependency on local compliance rules to build a common pipeline and (2) built replication system to support moving data across different
204 marketplaces. The global registration trial is restrictive as (1) it does not support all countries and payment instruments, (2) does not
205 support expansion to all marketplaces for existing Sellers, (3) complex user experience resulting from concatenation of compliance/tax
206 driven regional experiences and (4) few technical limitations that are covered subsequently.
207
208 SWIPE models registration experience into set of pages (or pipeline). A page in SWIPE is composed of set of fragments. A fragment is the
209 smallest data collection unit in SWIPE which encapsulates the business logic to collect a specific type of data. Figure 1 shows how
210 registrations pipelines are built on SWIPE. The NA registration pipeline shown in this figure has two pages. The first page is the seller
211 information page that has two fragment - name and address. The EU registration pipeline on the other hand has the same fragments with
212 a completely different set of configurations. Registration pipelines are disjoint and there are no interactions between them. However,
213 fragments are reused in registration pipelines. Fragments are libraries that can be deployed to the stack that hosts the registration
214 pipeline. Fragments along with the configurations are deployed with each web stack. Fragments started simple but became complex over
215 time. As fragments have to support multiple use-cases, for example address fragment had to support all types of addresses like billing
216 address, shipping address etc., features specific to use-cases have to be added, which require configurations. Additionally, as the same
217 library is used in multiple stacks, configurations are added to enable/disable features as guard rails. In order to reduce configurations, we
218 added hierarchical fallback, which while reduced configurations, increased cognitive load as the same configuration might now impact
219 multiple different pipelines. Configurations have become our single biggest paint point. Here are some of the limitations of SWIPE that
220 are slowing us down:
221 1. Coupled presentation and business logic makes it hard to support mobile or global registration. SWIPE enforces no clear separation
222 of presentation and business logic. This makes it hard to support different presenters like mobile and also makes it hard to build global
223 registration. Global registration requires copying data that we collect to all marketplaces. This requires business logic (headless) to be
224 separate from the presentation (head).

Amazon Confidential 7 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
225 2. Complex configuration limits the velocity of development. The complexity arises from the flexibility we added Each fragment broadly
226 has four categories of configuration (1) configuration controlling the view (field label, properties, validations, dropdown values, etc. have
227 to been defined through configurations), (2) configuration controlling the business validations and (3) configuration needed to attach a
228 fragment to a page and (4) configuration to stitch the pages together. The configuration has a loosely typed schema that (1) limits
229 readability, (2) makes it very generic and (3) results in lot of duplication. Understanding these configurations has a significant learning
230 curve and it has become the single biggest pain point for SDEs.
231 3. Flexibility that we need to support business growth is missing. In theory fragments are designed for reuse which is why they are
232 configuration heavy, however in practice they are not reusable. As fragments are generic, creating a pipeline involves adding the business
233 rules either by (1) extending the fragment or (2) writing them as code between the fragments. This limits the reusability of fragments as
234 business logic is spread outside the fragment into pipelines. This makes (1) each registration pipeline distinct and (2) makes it hard to
235 experiment. A simple experiment of introducing a new field or reordering pages requires duplicating the entire pipeline.
236 4. Testing is hard. Each fragment is not testable by itself. Fragments can be visualized as loosely typed libraries deployed to multiple stacks.
237 This complicates deployment and makes testing extremely hard. A good analogy for this is inheritance in classes. Fragments are lik abstract
238 class and have to be implemented each time they are used. Now, when the base class changes, the implementations are invalidated.
239 When this happens in a language like Java, the compilation fails and its easy to pin point to the exact issue. However, with fragments this
240 can be identified only during runtime. The makes loyments hard as any change to the fragment requires testing the entire registration
241 pipeline. Testing is complicated due to the fact that it is hard to assess the impact of any fragment code change.
242 5. Centralized ownership is a bottleneck. Currently our ownership model is at the pipeline level (EU pipeline, NA pipeline etc.)
243 Registrations team owns all the functionality which requires the team to build diverse functional expertise and slows us down.
244
245 B. RAMP Architecture
UI Services like SIVIS/API calls/RAMP Legacy Widgets/other external services

RAMP Status Service (RSS) ODS RAMP Delta Service (RDS)

(Onboarding Data Store)

CAPE
Verification Orchestration Service (VOS)
COSMOS

Compliance Platform (CP)

Verification Primitive Service
Checkpoint

Cairo/Giza Noir
(3P Vendors) Nautilus
Figure 3: RAMP Architecture
246
247 Figure 3 shows the current architecture of RAMP. Here are some of the limitations of RAMP that are slowing us down:
248 1. Unnecessary Flexibility. Due to our prior understanding of the compliance space (with Flexible Payments Service), we intended to
249 create RAMP with enough flexibility to handle changing compliance requirements. A lot of RAMP low level decisions kept this flexibility
250 in mind and allowed the low-level workflow, service, and database structures to be highly flexible with usage of type parameters and
251 deeply nested JSON objects. A single verification requires configurations to the extent of an account, its entities, the related entities, the
252 data for the entities, encryption schemes for the data, etc. We also depended heavily on configurations and only kept the configuration
253 execution functionalities in code. This flexibility, however, complicated the configurations over time. An example of the flexibility would
254 be the way RAMP defines a verification workflow step. It is a generic step which does all types of verifications like auto IDV, DPL, PEP,
255 etc. This workflow has bloated as it needs to accommodate all types of verifications in a configurable manner.
256 2. Missing abstractions. Current architecture does not have a layered abstraction from clients’ perspective. Through VOS plan and RDS
257 rulesets, we are opening up the complete verification process down to the lowermost predicate and attribute details. This has led to the
258 problem of too many variables, which adds unnecessary complexity for clients to understand. Onboarding time is high because of the
259 granular details that the clients need to understand.
260 3. Workflow Management. RAMP has an internal workflow (a dependency graph (DG) based workflow engine), which controls the
261 overall customer verification flow. The DG orchestrator works inside out. Plugging any custom logic between the RAMP workflow steps
262 is very difficult and time consuming. The orchestrator gets triggered implicitly/explicitly when accounts or entities get created and works
263 through a preset configuration which manages the verification process as well as end-customer experience aspects. While the DG works
264 well for the verification execution, it gets overly complicated for managing the customer experience. For example, while executing a
265 verification, it also supports APIs to dictate what data the end customer can edit/enter. This means having complex rulesets at each
266 workflow step level to dictate UI experience. It also leads to the problem of having an infinitely open workflow for SOA EU where RAMP
267 manages both onboarding time and post-onboarding account verifications.
268 4. Lack of clear service boundaries. Over time to fit in multiple use cases, services were overloaded with responsibilities even beyond
269 what it was intended to do. This leads to the forking out of flows that further led to maintenance issues. For e.g. In the SOA EU flow,

Amazon Confidential 8 October 15, 2019

 Seller Registration and Verification 3YAP Appendix
270 since the Compliance platform could not introduce a new identity verification proof type, VOS took up the responsibility of performing
271 an internal mapping. Even though this flow seemed a straight forward translation, it led to multiple issues going ahead as the code
272 forked out based on the translation. Another example is the storage of non-Boolean results in RSS which it was never intended to do.
273 5. Inter service communication. Asynchronous communication between RAMP services through SNS-SQS creates a communication
274 blind spot and overhead. While this is not the main factor for RAMP latency, it does complicate the system. The notifications make sense
275 for RAMP clients, using them for orchestrating flows within RAMP added overhead. The asynchronous communication along with the
276 fact that the system is majorly configuration driven made it extremely hard to add component tests for the services. The teams had to
277 depend heavily on the end to end tests which slowed down the overall development process.

Amazon Confidential 9 October 15, 2019