GNC Utility Block - AEO Mutual Recognition

GNC Utility Block - AEO Mutual Recognition

2013-04-11 Version 1.20 1

GLOBALLY NETWORKED CUSTOMS

UTILITY BLOCK

AEO MUTUAL RECOGNITION

PROPOSED BY EU AND US


2013-04-11 Version 1.20 2

INTRODUCTION

0.1. Purpose of this document

This document provides a first version of a Globally Networked Customs (GNC) Utility

Block (UB) for the Authorised Economic Operator (AEO) Mutual Recognition (MR).

It is built on the UB structure endorsed by the GNC Ad-Hoc Group.

0.2. Utility Block Executive Summary

PURPOSE To specify the process that regulates the information

interaction between partners, and involved traders, that

subscribe to an AEO Mutual Recognition

Arrangement/Agreement (MRA);

To enable each of the partners to grant benefits to AEOs of

all other partners;

To provide future partners negotiating a bilateral AEO

MRA with a template (this UB) for completing the

technical annex to exchange the AEO identities.

ADVANTAGE TO

GOVERNMENT Streamlined process for exchange of data allowing the re-

use of this same approach for all bilateral AEO MRAs to

which a WCO Member subscribes;

Reassurance of a consistent and coherent automatic

implementation of the bilateral AEO MRAs across all

partners, promoting all the foreseen benefits across the

geographical footprint of the bilateral AEO MRA (better

control targeting, as a direct result of more effective

automated risk analysis);

Low costs to establish the technical annex (using this UB

as the template) of their bilateral AEO MRA with high

opportunity for reuse and therefore reduction in the costs

for the IT implementation.

ADVANTAGES TO

BUSINESS /

STAKEHOLDERS

Transparency and predictability of the AEO benefits

granted by all partners of the MRA;

Reassurance that the partners are committed to successfully

implement the bilateral AEO MRA and to grant benefits to

the recognised AEO (facilitation, lower risk score,

reduction of control at export and import, expedited

release time) in a systematic and predictable way;

Brings a full transparency on the Trader Identification

Number(s) (TIN) that need to be used with each of the

partners to ensure the recognition of their AEO status.

LEGAL

FRAMEWORK

AND COMPLIANCE

Legal Framework – all bilateral AEO MRAs between

partners;

Compliance - the partners must ensure that the AEO

information exchanges and all related data comply with the

data protection legislation of each partner; that the data

remains secured in their respective systems and is

synchronised across the IT systems of all involved parties.


2013-04-11 Version 1.20 3

The availability of the AEO information is specified and

measures are defined, in the case where AEO information

would not be available for the processing of a Customs

notification or Customs declaration.

ENTITIES LAYER Partner refers to the contracting party to the bilateral AEO

MRA, (e.g. National Administration for Customs). It is

important to note that every partner will act in two distinct

roles:

“Granting” role: As the “Granting” partner allocating the

AEO status to a trader, performing re-assessment and

evaluation of this AEO.

“Lodgement” role: As the “Lodgement” partner

processing a notification/declaration lodged in its Customs

transaction system by a trader.

Trader refers to the economic operators which play an active

supporting role in the information exchange underpinning the

bilateral AEO MRA process. Two trader roles participate in

the bilateral AEO MRA process:

“AEO”: As the trader certified as an AEO by the

“Granting” partner;

“Lodging” trader: As the trader lodging a

notification/declaration to the “Lodgement” partner

making reference to his AEO status and the AEO status of

his partners.

The bilateral AEO MRA process choreographs the exchange

of information between the partners. The two trader roles are

included in order to illustrate the end-to-end process.

However, it must be noted that the first pillar of the GNC only

covers Customs-to-Customs interactions.

BUSINESS RULES

LAYER

Comprises a number of detailed rules concerning the

following:

Contact points between partners;

Requirements for:

o the AEO information;

o the trader as one of the supporting participants in the

end-to-end business process;

o Customs transaction systems in the “Lodgement”

partner;

o the risk analysis systems in the “Lodgement” partner;

o AEO Identity Management and, in particular, the

aliasing process by the “Lodgement” partner;

o the nature and frequency of data exchange, monitoring

and statistical requirements.

The compliance of all partners of the bilateral AEO MRA

to the WCO standard regarding the TIN structure is a

MAJOR simplification opportunity in the implementation

of this UB.

DATA CLUSTER

LAYER

The UB relies on the exchange of two functional messages:

“Granted” AEO information;


2013-04-11 Version 1.20 4

“Alias” TIN between the “Granting” partner and the

“Lodgement” partner.

The associated rules, supporting codes and dictionary are

detailed further in this document.

TRIGGER LAYER The UB features three variations for choreographing the

interactions between the partners according to the following

criteria:

Whether or not there is the need for the “Lodgement”

partner to assign an “Alias” TIN (triggered by misaligned

structures of the TIN numbers between the partners);

and in the case of alignment1 of the TIN structure between

the partners, the choice for a “Lodgement” partner to opt

for a “Pull” mode (instead of “Push” mode)2 to access the

AEO information from the “Granting” partner.

The three options are:

“Push” of “Granted” AEO information and “Push” back of

“Alias” TIN between the “Granting” partner and the

“Lodgement” partner, for those cases that the partners

have misaligned TINs;

“Push” of “Granted” AEO from the “Granting” partner to

the “Lodgement” partner when partners have aligned

TINs;

“Pull” of the “Granted” AEO information by “Lodgement”

partner from the “Granting” partner, which requires TIN

alignment.

INTERFACE LAYER The UB defines the set of four technical messages associated

with the following three options in the trigger layer:

“Granted” AEO information is sent from the “Granting”

partner and the “Alias” TIN is returned from the

“Lodgement” partner, for those cases that the partners

have misaligned TINs;

When partners have aligned TINs, “Granted” AEO is sent

from the “Granting” partner to the “Lodgement” partner;

“Granted” AEO information is acquired directly by the

“Lodgement” partner from the “Granting” partner.

It also provides the technical messages in Extensible Markup

Language (XML) schemas and Web Services definition in

Web Services Definition Language (WSDL).

INTEGRATION

LAYER

The integration layer needs to be profiled by each partner

during the negotiation process of the Bilateral AEO MRA.

This includes the business case for national profiling, the use

of the AEO information for the risk assessment of

notification/declaration, and national provisions for AEO

identification. It also sets the requirement for the availability

of the exchanged data, provides an indication of the possible

1 TIN aligned refers to the compliance of the AEO structure and policy.

2 A detailed explanation on the “Pull” and “Push” methods is described in chapter 4.2


2013-04-11 Version 1.20 5

data volumes, and the compliance and infrastructure

requirements.

COMMUNICATION

LAYER

The information exchanges take place over the internet. The

security of the exchanges is ensured by encryption using

security certificates.

GOVERNANCE

The Governance section provides a starting point and basis to

define the project governance structure between the partners.

It provides a template for the project plan, the organisation of

the test phase, the Operational Level Agreement between the

partners, the help desk arrangements and escalation

mechanisms. In addition, the change management process of

the technical annex of the bilateral AEO MRA, based on a

change management board is included.

CAPACITY

BULDING

Several options are presented to promote the roll-out of this

UB with partners that have limited IT capacity:

all “Granting” partners should offer access to their

“Granted” AEO via a web interface/application, as long as

they have given their agreement for their information to be

published. Each partner ultimately decides if the access via

web interface will be offered and made available;

any technology provider with software that will assist

WCO members in implementing GNC, for example,

Automated System for Customs Data (ASYCUDA) that is

used in a number of Customs agencies could embed the

role of the “Lodgement” partner and of the “Granting”

partner, as a low cost option;

the lite and fat hubs will decrease the entry costs for their

client partners. However, funding arrangements are

required to support the set up and operation of these hubs.

0.3. Intended readership

The document is addressed to:

The WCO function which will be responsible for the deployment of GNC to review

and comment on the structure and content of the UB;

The WCO SAFE working group and any other WCO groups as deemed necessary to

review and comment on the structure and content of the UB;

Any person involved in the establishment of an international arrangement/agreement

on AEO MR to provide suggestion regarding the improvement of the material

provided;

Any person responsible for the implementation of AEO information exchange

between countries to provide inspiration to set up such exchange of AEO-identities.


2013-04-11 Version 1.20 6

0.4. Structure of this document

The document is structured as follows:

Chapter 1: this chapter explains the purpose of the AEO MR UB, including its

purpose for the partners involved;

Chapter 2: this chapter explains the advantages of adopting this AEO MR UB to

implement an AEO MRA;

Chapter 3: this chapter explains the legal framework and compliance requirements

when adopting this AEO MR UB;

Chapter 4: this chapter explains the business process of how the AEO MRA

information is exchanged between partners;

Chapter 5: this chapter explains the IT Process of how the AEO MRA information is

exchanged and implemented between partners;

Chapter 6: this chapter explains the governance between partners and how to govern

the implementation of the AEO MR UB;

Chapter 7: this chapter presents the template to be filled in by partners that explains

how their AEO MRA will be implemented;

Chapter 8: this chapter explains how the implementation of the AEO MR UB

impacts capacity building;

Annex 1: presents the codes used for data types and requirements in the message

structures;

Annex 2: presents the business codes and data dictionary;

Annex 3: presents the XSD and WSDL files.


2013-04-11 Version 1.20 7

0.4.1. Table of Contents

0.1. Purpose of this document .................................................................................. 2

0.2. Utility Block Executive Summary ..................................................................... 2

0.3. Intended readership ............................................................................................ 5

0.4. Structure of this document ................................................................................. 6

0.4.1. Table of Contents ................................................................................ 7

0.4.2. List of Figures ...................................................................................... 9

0.4.3. List of Tables ..................................................................................... 10

0.5. Acronyms and abbreviations ........................................................................... 11

0.6. Reference Documents ...................................................................................... 12

0.7. Implementation History ................................................................................... 13

1. PURPOSE ................................................................................................................. 14

2. ADVANTAGES ........................................................................................................ 16

2.1. Government ..................................................................................................... 16

2.2. Business/Stakeholders ..................................................................................... 16

3. LEGAL FRAMEWORK AND COMPLIANCE ....................................................... 17

3.1. Legal framework .............................................................................................. 17

3.2. Compliance ...................................................................................................... 17

3.2.1. Consistency of data ............................................................................ 18

3.2.2. Security .............................................................................................. 18

3.2.3. Data Protection .................................................................................. 18

3.2.4. Availability of exchanged data .......................................................... 19

3.2.5. Business Continuity ........................................................................... 20

4. BUSINESS PROCESS .............................................................................................. 22

4.1. Entities Layer ................................................................................................... 22

4.2. “Push”and “Pull” mode ................................................................................... 22

4.3. Business Rules Layer ....................................................................................... 23

4.3.1. Contact points between partners ........................................................ 23

4.3.2. Requirements for the AEO information ............................................ 23

4.3.3. Requirements for the trader ............................................................... 24

4.3.4. Requirements for Customs transaction systems in the

“Lodgement” partner ......................................................................... 24

4.3.5. Requirements for the risk analysis systems in the

“Lodgement” partner ......................................................................... 24

4.3.6. AEO Identity Management ................................................................ 25

4.3.7. Frequency of data exchange .............................................................. 27

4.3.8. Monitoring & statistical requirements ............................................... 28

4.4. Data cluster layer ............................................................................................. 28

4.4.1. Functional messages .......................................................................... 28

4.4.2. Languages and character sets ............................................................. 29

4.4.3. Data volume ....................................................................................... 29

4.5. Trigger layer .................................................................................................... 29

4.5.1. The “Alias” TIN case ......................................................................... 30

4.5.2. The “Granted” AEO TIN case - “Push” mode .................................. 33

4.5.3. The “Granted” AEO TIN case - “Pull” mode .................................... 36

4.5.4. Combination amongst cases .............................................................. 39

5. IT PROCESS ............................................................................................................. 40

5.1. Interface layer .................................................................................................. 40


2013-04-11 Version 1.20 8

5.1.1. “Alias” TIN case ................................................................................ 40

5.1.2. “Granted” AEO TIN case - “Push” mode .......................................... 54

5.1.3. “Granted” AEO TIN case - “Pull” mode ........................................... 54

5.1.4. Statistics and monitoring ................................................................... 62

5.2. Communication layer ...................................................................................... 63

5.2.1. Networking ........................................................................................ 63

5.2.2. Security .............................................................................................. 64

6. GOVERNANCE ....................................................................................................... 69

6.1. Structure .......................................................................................................... 69

6.2. Project .............................................................................................................. 69

6.2.1. Implementation roadmap ................................................................... 69

6.2.2. Testing ............................................................................................... 71

6.3. Operational Level Agreement .......................................................................... 72

6.3.1. Frequency .......................................................................................... 72

6.3.2. Availability ........................................................................................ 72

6.3.3. Troubleshooting ................................................................................. 73

6.3.4. Help-Desk .......................................................................................... 73

6.4. Change Management ....................................................................................... 74

7. INTEGRATION LAYER (TO BE FILLED IN BY THE PARTNERS) ..................... 75

7.1. Business case partners interaction ................................................................... 75

7.2. Business case national profiling ...................................................................... 78

7.3. AEO identification national provisions ........................................................... 78

7.4. Security ............................................................................................................ 79

7.5. Availability of exchanged data ........................................................................ 79

7.5.1. Availability of exchanged data to the Customs transaction

systems (declaration systems) ............................................................ 79

7.5.2. Availability of exchanged data to the risk management .................... 80

7.5.3. Availability of exchanged data to trade operators ............................. 80

7.6. Data volume ..................................................................................................... 80

7.7. Compliance ...................................................................................................... 81

7.8. IT Architecture ................................................................................................ 81

7.9. Infrastructure ................................................................................................... 82

8. CAPACITY BUILDING ........................................................................................... 83

ANNEX 1: CODES USED FOR DATA TYPES AND REQUIREMENTS IN

THE MESSAGE STRUCTURES ............................................................................. 84

ANNEX 2: BUSINESS CODES AND DATA DICTIONARY ....................................... 85

ANNEX 2.1: BUSINESS CODES ........................................................................... 85

ANNEX 2.2: DATA DICTIONARY ....................................................................... 86

ANNEX 3: XSD AND WSDL .......................................................................................... 90

ANNEX 3.1: XSD ........................................................................................................ 90

ANNEX 3.1.1: AEO MESSAGES XSD .................................................................. 90

ANNEX 3.2 WSDL ................................................................................................... 105

ANNEX 3.2.1: GNCAEOPush ........................................................................ 105

ANNEX 3.2.2: GNCAEOPull ......................................................................... 106

ANNEX 3.2.3: GNCStatisticsPull ................................................................... 108


2013-04-11 Version 1.20 9

0.4.2. List of Figures

Figure 1: Sequence diagram - “Alias” TIN case ............................................................... 31

Figure 2: BPMN2.0 diagram - “Alias” TIN case.............................................................. 32

Figure 3: Sequence diagram - “Granted” AEO TIN case - “Push” mode ........................ 34

Figure 4: BPMN2.0 diagram - “Granted” AEO TIN case - “Push” mode ....................... 35

Figure 5: Sequence diagram - “Granted” AEO TIN case - “Pull” mode .......................... 37

Figure 6: BPMN2.0 diagram - “Granted” AEO TIN case - “Pull” mode ......................... 38

Figure 7: Technical protocol for “Push” mode ................................................................. 41

Figure 8: XSD Structure of the “Push” message .............................................................. 50

Figure 9: XSD Structure of the “Granted” AEO within the “Push” message .................. 51

Figure 10: XSD structure of the Equivalence message .................................................... 52

Figure 11: XSD structure for the Results message ........................................................... 53

Figure 12: Technical protocol for “Pull” mode ................................................................ 54

Figure 13: Sample GUI ..................................................................................................... 58

Figure 14: XSD Structure of the “Pull” message ............................................................. 59

Figure 15: XSD Structure of the Request AEO “Pull” message ...................................... 60

Figure 16: XSD Structure of the “Granted” AEO “Pull” message ................................... 61

Figure 17: Statistics and monitoring request and response .............................................. 62

Figure 18: Secure “Push” using Web Services ................................................................. 64

Figure 19: Secure “Pull” using Web Browser .................................................................. 67

Figure 20: Example of Project plan .................................................................................. 70

Figure 21: AEO MR Business process and its integration in the partners' Customs

processes –“Push” mode........................................................................................... 76

Figure 22: AEO MR Business process and its integration in the partners' Customs

processes – “Pull” mode ........................................................................................... 77


2013-04-11 Version 1.20 10

0.4.3. List of Tables

Table 1: Acronyms and abbreviations .............................................................................. 11

Table 2: Reference Documents......................................................................................... 12

Table 3: Implementation History ...................................................................................... 13

Table 4: Consistency of data ............................................................................................ 18

Table 5: Security ............................................................................................................... 18

Table 6: Data Protection ................................................................................................... 19

Table 7: Availability of exchanged data ........................................................................... 19

Table 8: Business continuity............................................................................................. 21

Table 9: Contact points ..................................................................................................... 23

Table 10: Requirements for the AEO data ....................................................................... 24

Table 11: Requirements for the trader .............................................................................. 24

Table 12: Requirements for Customs systems in the “Lodgement” partner..................... 24

Table 13: Requirements for the risk analysis systems in the “Lodgement” partner ......... 25

Table 14: TIN ................................................................................................................... 27

Table 15: Multiple TIN .................................................................................................... 27

Table 16: Frequency of data exchange ............................................................................. 27

Table 17: Monitoring & statistical requirements .............................................................. 28

Table 18: Language and character sets ............................................................................. 29

Table 19: Data volume ..................................................................................................... 29

Table 20: Trigger layer ..................................................................................................... 30

Table 21: Business case national profiling ....................................................................... 78

Table 22: AEO identification national provisions ............................................................ 79

Table 23: Security ............................................................................................................. 79

Table 24: Availability to the Customs transaction systems .............................................. 80

Table 25: Availability to the risk management ................................................................ 80

Table 26: Availability to trade operators .......................................................................... 80

Table 27: Data volume ..................................................................................................... 80

Table 28: Compliance....................................................................................................... 81

Table 29: IT Architecture ................................................................................................. 81

Table 30: Infrastructure .................................................................................................... 82

Table 31: Codes used for data types and requirements .................................................... 84

Table 32: Business codes .................................................................................................. 85

Table 33: Data Dictionary ................................................................................................ 89


2013-04-11 Version 1.20 11

0.5. Acronyms and abbreviations

The following acronyms are used in this document:

Abbreviation or

Acronym

Description

AEO Authorised Economic Operator

ASYCUDA Automated System for Customs Data

BPM Business Process Modelling

CMB Change Management Board

CR Change Request

EORI Economic Operators' Registration and Identification System

EOS Economic Operators System(s)

EC European Commission

EU European Union

GNC Globally Networked Customs

GUI Graphical User Interface

GUID Global Unique Identifier

ISO International Standard Organisation

IT Information Technology

ITSM IT Service Management

MoF Ministry of Finance

MR Mutual Recognition

MRA Mutual Recognition Arrangement/Agreement

NCTS New Computerised Transit System

PIP Partner in Protection

SOAP Simple Object Access Protocol

TA Technical annex of the MRA

TIN Trader Identification Number

UB Utility Block

XML eXtensible Markup Language

XSD XML Schema Definition

WCO World Customs Organisation

WSDL Web Service Definition Language

Table 1: Acronyms and abbreviations


2013-04-11 Version 1.20 12

0.6. Reference Documents

Ref. Title Publishing

Organisation

Version Date

R1 Guidelines for developing a

Mutual recognition

arrangement/agreement

WCO WCO Council June 2011

R2 GNC UBs – Enablers of Inter-

operability, presentation

Government of India

Ministry of Finance

(MoF)

April 6, 2011

R3 Letter from WCO WCO 11.FL-

0278E/G.

L.

September 27, 2011

R4 WCO data model Data SET

(10102011)

WCO V3.2 September 29, 2011

R5 Implementation_of_the_Mutual

_Recognition_Agreement_with

_US_CBP-Phase1

TAXUD V 1.0 May 4, 2012

R6 SAFE Framework WCO June 2007

R7 WCO SAFE Framework

Standards

WCO June 2011

R8 GNC Architecture 10th GNC Ad hoc

group

V0.1 February 9,2012

R9 GNC Feasibility Study GNC Ad hoc group

Table 2: Reference Documents


2013-04-11 Version 1.20 13

0.7. Implementation History

This UB has currently been considered for the following AEO MRA:

AEO MRA reference Partners Status at date of publishing

Table 3: Implementation History


2013-04-11 Version 1.20 14

1. PURPOSE

The implementation of a Bilateral AEO MRA needs to be underpinned by a process

ensuring the timely availability and processing of information to enable the participating

partners to grant benefits to AEO programme members. The agreement foresees the

exchange of AEO data between the partners allowing certain benefits to be granted to the

mutually recognised authorised economic operators.

The purpose of the UB for AEO is to specify the process regulating the information

interaction between partners that subscribe to a bilateral AEO MRA. The high level

interaction with the involved economic operators is described for completeness; but it is

not part of the implementation of this UB. This UB proposes a template for the technical

annex of the Bilateral AEO MRA and therefore, will save time and reduce costs for

partners to implement this UB. It also makes it possible to reuse their IT

implementation/infrastructure of this UB for other future possible UBs.

Furthermore, this UB will enable:

- The possibility of economic operators submitting data for goods entering or

leaving the Customs territory to declare its secure supply chain partners, certified

by other partners, and as a consequence, be eligible for the mutually agreed

benefits;

- The Customs authorities to identify AEOs certified by partners and declared in

their Customs transactions, in order to grant the AEO the mutually agreed

benefits.

However, the following conditions will need to be fulfilled:

- For the person submitting data to Customs authorities for goods entering, transiting or

leaving the Customs territory:

To have up-to-date data of the TIN or “Alias” TIN certified in the relevant partner

country at its disposal;

To be able to declare the AEO status (e.g. granted by a partner) of its secure

supply chain partners involved in a specific Customs transaction.

- For the Customs authorities:

To have up-to-date data of AEOs certified by any of the partners at its disposal;

To be able to identify and recognise these AEOs when used in declarations for

goods entering, transiting or leaving the Customs territory;

To be able to take account of the AEO status granted by any of the partners when

performing risk analysis;

To grant the level of agreed benefits to economic operators corresponding to their

AEO status or those of their supply chain partners.

- For the AEOs involved in a Customs transaction/procedure:

To be eligible for the appropriate level of AEO benefits, if its AEO status is

declared and recognised in any advanced cargo notification or other declaration

submitted to Customs in all partners.


2013-04-11 Version 1.20 15

The UB defines how partners share and use their AEO information. It defines which

interactions they may have at the national level with the AEO and the “Lodging” trader,

and more specifically, it defines how:

Each partner must:

o Implement AEO nationally before expanding to include international AEOs via an

MRA;

o Share the information of its AEO with the other partners;

- If necessary assign the AEO TIN with an “Alias” TIN in order to allow the

lodging of the declaration. This involves informing its partners of any

“Alias” TIN, i.e. for identification, where an "Alias" TIN is defined for the

purpose of referring to the AEO status in a notification/declaration lodged

to the “Lodgement” partner;

- Inform their AEOs of their “Alias” TIN that its partners may have issued.

o Use the information of the AEOs of its partners for the purpose of risk analysis of

notification/declaration lodged.

Each AEO must pre-inform the “Lodging” trader of its TIN or “Alias TIN” in the

“Lodgement” partner. This information exchange is trade-to-trade and not in scope of

this UB;

Each “Lodging” trader in the “Lodgement” partner may include the “Alias TIN” of the

AEO, if applicable. This information exchange is nationally defined.

This document identifies the impact on both the Customs transaction systems and the risk

analysis systems of the partners. This is based on the assumption that these systems will

need to identify the AEOs that have been declared in a Customs transaction and that these

data will be used for the purpose of risk analysis. The scope of this document will define

the respective basic user requirements arising from this initiative.

However, the application of AEO benefits, the impact of the AEO status on the risk

assessment, on the risk scores and on the level of inspections are not in scope of this

document.


2013-04-11 Version 1.20 16

2. ADVANTAGES

This chapter lists all the advantages for the involved stakeholders.

2.1. Government

The following advantages are envisaged for the governments of the partners:

A streamlined process for the data exchange allowing re-use of the approach for all

Bilateral AEO MRAs to which a WCO Member subscribes;

Reassurance of a consistent and coherent automatic implementation of the bilateral

AEO MRAs across all partners, promoting all the foreseen benefits across the

geographical footprint of the bilateral AEO MRA (availability of more trader

information will enhance the risk analysis and security of the supply chain);

Low costs to establish the technical annex (using this UB as the template) of their

bilateral AEO MRA (which can be re-used in the context of other UBs) and

consequently, cost reduction for the IT implementation, faster implementation and an

increased time span of use.

2.2. Business/Stakeholders

The following advantages are envisaged for the business/stakeholders:

Reassurance that the partners are committed to successfully implement the bilateral

AEO MRA and to grant the same benefits to the recognised AEO (facilitation, lower

risk score, reduction of control at export and import, expedited release time) in a

systematic and predictable way;

Full transparency on the TINs that need to be used in each partner to ensure the

recognition of their AEO status.


2013-04-11 Version 1.20 17

3. LEGAL FRAMEWORK AND COMPLIANCE

3.1. Legal framework

The AEO MRA represents the legal basis and this UB serves as a template of the

technical annex to the AEO MRA and must follow the MRA. This technical annex

defines the process regulating the information exchange between the partners which

underpin the AEO MRA. Where partners draft an MRA, they are invited to use the UB as

a template for the technical annex.

The AEO MRA itself must be aligned with the SAFE framework [Reference Documents

R6]. The MRA drafted between partners is inherently bilateral however this UB supports

both bilateral and multilateral forms of MRA.

The AEO MRA must specify the key date for the Final Operation Capability, while its

technical annex will provide the detailed roadmap to implement the MRA in a

coordinated way across all partners. The roadmap will include test dates and initial

operational capability.

3.2. Compliance

The partners must ensure that the AEO information exchanges comply with the data

protection legislation of each partner, that data transfer is secured and data consistency is

provided. The availability of the AEO information is specified; and measures are defined

in the case that the AEO information would not be available for the processing of a

Customs notification or a Customs declaration.


2013-04-11 Version 1.20 18

3.2.1. Consistency of data

Identifier User requirement Remarks

UR CONS 1 The business data elements sent shall comply with the

business message specifications outlined in this document

(content and structure of the message).

It needs to be decided

whether error messages

need to be implemented

and how to deal with them

(to be decided on the

technical level).

UR CONS 2 Data received from other partners shall not be amended or

deleted by the receiving partner.

This requirement shall not

create a requirement for

implementing a function to

request the authorisation to

update or delete received

AEO records.

UR CONS 3 In cases according to UR BCAS 5 and UR BCAS 6

(unilateral suspension/revocation of benefits for all or

selected AEOs of a partner) the granting partner shall be

allowed to re-assess the AEO status and, if necessary, to

update the status of the relevant AEO records in accordance

with UR BCAS 3 (AEO status - suspended, revoked,

suspension annulled or revocation annulled).

Table 4: Consistency of data

3.2.2. Security


UR SECU 1

The data exchange between partners shall be secured; the

information and the information system shall be protected

from unauthorised access, use, disclosure, disruption,

modification or destruction.

The technical means to

secure the data exchange

shall be agreed on the

technical level.

UR SECU 2 Access to the exchanged data shall be restricted to authorised

actors and for authorised purposes.

Economic operators should

be able to consult only

published and publicly

available information.

UR SECU 3 It needs to be decided whether there is a need to agree on

rules for the traceability of creation, modification and

deletion of data.

To be decided on the

national level.

Table 5: Security

3.2.3. Data Protection


UR DATA 1 Deletion of an existing AEO record: For data protection

reasons, partners receiving AEO records from a “Granting”

partner shall delete these records and their corresponding

history on request of the “Granting” partner. The request

could be done using the “Push” message or via signed email.

The request for deletion

will be sent outside the

system.

UR DATA 2 The AEO shall have freely given specific and informed

consent for sending its data to the partner.

It is recommended that consent should be for all partners (i.e.

Functionality to identify (in

the system) the records for

which the AEO has given

its consent is required.


2013-04-11 Version 1.20 19


no selective consent depending on the partner).

For new records, an option

could be to implement the

consent in the application,

advising the operator that

the lack of consent

prevents him to benefit

from mutual recognition.

This implies that an

operator who decides not

to give his consent will not

benefit from mutual

recognition.

UR DATA 3 Need to comply with national data protection rules.

This is an integral part of

the AEO MRA.

Table 6: Data Protection

3.2.4. Availability of exchanged data


UR AV 1 The “Granting” partners must keep their AEO information

available to all partners who wish to access them in “Pull” mode 365/7/24 with a Quality of Service defined in the

Service Level Agreement (SLA).

The SLA will be defined

between partners when

specifying the technical

annex of their MRA.

UR AV 2 The partners must comply with the timing and frequency

requirements specified in 4.3.7 Frequency of data exchange,

to ensure the reliable exchange of AEO data.

The SLA will be defined

between partners when

specifying the technical

annex of their MRA.

Table 7: Availability of exchanged data


2013-04-11 Version 1.20 20

3.2.5. Business Continuity

There are various possible situations for which specific fallback solutions shall be put in

place. The following table summarises the various cases:

Identifier Situation Impact Fallback solution

BCON 1 Partner cannot

automatically send the

AEO data to its

partners.

The new or updated

AEO data is not

available to the

receiving partners.

Consequences in the

receiving partners:

Errors when automated

validation of the AEO

status of declared

parties in Customs

declaration systems

takes place;

Automated risk

analysis/targeting

cannot take account of

the AEO status of

declared parties and

cannot grant the agreed

benefits. The AEO in

the sending country is

not granted the expected

benefit;

Possibly unjustified

granting of benefits to

AEOs for which

updated information of

suspended or revoked

certificates is not

received in time.

Declarations/notifications

containing TIN of partners shall

not be rejected due to

unavailability of such (to be)

exchanged AEO data.

The only consequence of such

unavailability should be that the

AEO benefits mutually agreed

should not be applied to those

declarations/notifications unless

alternative (manual) arrangements

can be made e.g. manual check of

the AEO status via the web

interface/application, if available.

BCON 2 Partner cannot receive

the AEO data.

Same as for BCON1. Same as for BCON 1.

BCON 3 System in which the

exchanged AEO data

is recorded is offline.

The AEO data is not

available to users who

need to access the data;

AEO data cannot be

extracted and/or cannot

be sent to any other

system or stakeholder;

The AEO data is not

accessible and available

to other systems using

the data (e.g. Customs

declaration systems, risk

analysis).

To be defined at national level.

BCON 4 The Customs

declaration transaction

systems cannot access

the exchanged AEO

data.

Unjustified errors when

automated validation of

the AEO status of

declared parties in

Customs declaration

systems takes place;

Where reduced data

Same as BCON 3.


2013-04-11 Version 1.20 21

Identifier Situation Impact Fallback solution

sets for AEO are

implemented and

depending on the AEO

status of declared

parties: the pre-

conditions for the

reduced data sets cannot

be checked.

BCON 5 The risk analysis or

targeting system in

which the AEO data is

declared cannot access

the system where

exchanged AEO data

between partners is

stored.

Automated risk

analysis/targeting

cannot take account of

the AEO status of

declared parties and

cannot grant the agreed

benefits. The AEO in

the sending country is

not granted the expected

benefit;

Possibly unjustified

granting of benefits to

AEOs for which

updated information of

suspended or revoked

certificates is not

received in time.

Same as BCON 3.

Table 8: Business continuity


2013-04-11 Version 1.20 22

4. BUSINESS PROCESS

4.1. Entities Layer

The term “partner” refers to the contracting parties to the Bilateral AEO MRA. It is

important to note that every partner will act in two distinct roles:

The “Granting” role: As “Granting” partner allocating the AEO status to a trader,

performing the re-assessment and evaluation of this status;

The “Lodgement” role: As the “Lodgement” partner processing a

notification/declaration lodged in its Customs transaction system by a trader.

The term “trader” refers to the economic operators which play an active supporting role

in the information exchange underpinning the MRA process. It is also important to

recognise that traders will participate in the MRA process in two distinct roles:

“AEO”: As the trader who is certified AEO by the “Granting” partner;

“Lodging” trader: As the trader lodging a notification/declaration to the “Lodgement”

partner making reference to his and his partners AEO status.

.

The Bilateral AEO MRA process choreographs the exchange of information between the

partners. The two trader roles are included to illustrate the end-to-end process. However,

it must be noted that the first pillar of the GNC only covers Customs-to-Customs

interactions.

4.2. “Push”and “Pull” mode

In the context of the process, the “Push” and “Pull” modes are technical terms, which

refer to how AEO data is exchanged between partners.

The “Push” mode refers to the case where the owner of the information provides a

copy to the user;

The “Pull” mode refers to the case where the user of the information requests it from

the owner.

Depending on the mode adopted between partners, the requirements may vary. These

requirements will be highlighted in the following sections.


2013-04-11 Version 1.20 23

4.3. Business Rules Layer

4.3.1. Contact points between partners


UR ORGA 1 All partners shall establish the following contact points and

make their details available to all other partners:

contact point for technical issues;

contact point for business and organisational issues.

No system functionality

shall be implemented for

this purpose; the exchange

of the contact details shall

be made using alternative

means of communication.

The data shall be updated

on regular basis.

Table 9: Contact points

4.3.2. Requirements for the AEO information


UR BCAS 1 The “Granting” partner will keep the information record of

its AEO up-to-date and accessible to the partners.

To support the “Pull” mode.

UR BCAS 2 The following generic business scenarios shall be

supported and communicated by the “Granting” partner to

partners:

creation of a new AEO record;

update of an existing AEO record (e.g. in cases where

the AEO address details change);

deletion of an existing AEO record.

To support the “Push” mode.

Refer to section 3.2.3 - Data

protection.

UR BCAS 3 The following status changes shall be communicated by

the “Granting” partner to the partners:

suspension of an AEO status;

revocation of an AEO status;

annulment of a suspension;

annulment of a revocation.

To support the “Push” mode.

The most suitable mechanism

to communicate status

changes shall be specified at

technical level.

UR BCAS 4 The exchange shall be for economic operators holding

AEO certificates only.

UR BCAS 5 A partner shall have the possibility to unilaterally

suspend/revoke the benefits for all of the AEOs of another

partner without delay.

This requires a functionality to identify in the system the

partner for which the benefits are suspended or revoked.

Partners are entitled to

suspend /revoke benefits of

other partners' AEOs on their

territory but are not entitled to

revoke or suspend their AEO

status as such. In this context,

whenever talking about

benefits, the reference is to

the benefits listed in the

relevant MRA.

Unilateral suspensions and

revocations shall be

communicated without delay

and by alternative means to

the partner which has granted

the AEO status (no system

functionality to be created for


2013-04-11 Version 1.20 24

this purpose).

UR BCAS 6 A partner shall have the possibility to unilaterally

suspend/revoke the benefits for specific AEOs of another

partner without delay.

This requires a functionality to identify in the system the

AEO of the partners for which benefits are unilaterally

suspended or revoked.

Same as UR BCAS 5

Table 10: Requirements for the AEO data

4.3.3. Requirements for the trader


UR BCAS 7 The AEO trader must communicate its TIN to the “Lodging”

trader.

Implementation under the

responsibility of the traders

and not to be supported by

the automated AEO process

between partners. This

requirement will be part of

GNC Pillar 2.

UR BCAS 8 The “Lodging” trader must include the AEO TIN in the

Customs notification/declaration that it is being lodged to a

partner to get the benefit of the AEO MR.

Implementation in the

trader system. This

requirement will be part of

GNC Pillar 2.

Table 11: Requirements for the trader

4.3.4. Requirements for Customs transaction systems in the “Lodgement”

partner


UR CTAS 1 The partners' systems used for declaring goods entering and

leaving the Customs territory (and if relevant, including

transit) shall contain the data fields needed to declare the

relevant AEO TIN assigned by any of the partners.

To be defined at national

level

UR CTAS 2 Where reduced data sets for AEO are implemented, and

dependent on the AEO status of parties other than the sender

of the declaration, the necessary data fields for declaring the

others’ AEO TIN shall be available in the declarations.


level

Table 12: Requirements for Customs systems in the “Lodgement” partner

4.3.5. Requirements for the risk analysis systems in the “Lodgement” partner


UR RANS 1 The partners' systems used for analysing the risk for goods

entering, transiting and leaving the Customs territory shall

recognise the declared AEO TIN assigned by any of the

partners and be able to grant the agreed AEO benefits.


level


2013-04-11 Version 1.20 25


UR RANS 2 Where the risk analysis has to take account of the AEO status

of parties other than the sender of the declaration, the

necessary data fields for declaring the other's AEO TIN shall

be provided to the risk analysis.


level

UR RANS 3 When the MR between two partners provides for lower risk

scores or less controls for their mutually recognised AEOs,

the declared AEO TIN is the key to identifying these parties

and should be taken into account when performing risk

analysis.


level

Table 13: Requirements for the risk analysis systems in the “Lodgement”

partner

4.3.6. AEO Identity Management

4.3.6.1. TIN


UR IDEN 1 The “Granting” partner must assign a TIN to each of the

AEO that it certifies. The TIN shall be in Latin characters.

UR IDEN 2 The “Granting” partner must issue TIN to its AEO which:

must use ASCII characters only and not use language

dependent and special characters;

should comply with the WCO TIN standard [Reference

Documents R4]: ISO alpha 2 country followed by

an..15, in order to facilitate the TIN interoperability

between partners.

Compliance with the

WCO TIN standard

[Reference Documents

R4] will reduce the

cost of the IT

implementation for the

partners which comply

with this standard;

Compliance with the

WCO TIN standard

[Reference Documents

R4] will benefit the

trade as it is not

necessary to maintain

as many TIN as

Customs

Administrations it

deals with;

In addition, it will offer

opportunity of

significant cost savings

for future IT

implementation of

agreements calling for

the sharing of TIN

amongst partners.

UR IDEN 3 The “Granting” partner (systems) in which the AEO records

are held should offer a functionality which enables its users

to query for all the existing TIN (records) for the same

trader.

For the partners to decide.

This is not a user

requirement that sets

obligations for the

envisaged data exchange

system.


2013-04-11 Version 1.20 26


UR IDEN 4 The TIN shall be communicated only once between partners.

The certificate can change its status during the time.

The assumptions are:

That the AEO can be

identified based on its

TIN;

That an AEO can have

only one valid and

relevant AEO

certificate per partner

at a given moment in

time.

UR IDEN 5 The partners (systems) shall be able to recognise and handle

AEO TINs assigned by the “Granting” partners, as specified

in the interface layer.


level

UR IDEN 6 The partners should :

assign a TIN to their “Lodging” traders which comply

with the WCO TIN standard [Reference Documents R4]

ISO alpha 2 country followed by an..15, in order to

enable the TIN interoperability between partners;

have transaction and risk management systems which are

able to process both “Lodging” trader TIN and

“Granted” AEO TIN which comply with the WCO TIN

standard [Reference Documents R4] .

This will significantly

reduce the cost of IT

implementation of the

Bilateral AEO MRA for the

complying partners.

In addition, it will offer

opportunity of significant

cost savings for the future

IT implementation of

agreements calling for

sharing of TIN amongst

partners.

UR IDEN 7 If the “Lodging” partner can process the “Granted” AEO

TIN in its transaction and risk management system, the

partner must choose between the “Pull” or “Push” mode to

retrieve the “Granted” AEO TIN as needed for its transaction

and risk management system.

“Pull” mode approach is

the highly recommended

option and likely to be only

achievable in the medium

and long term as the TIN

standardisation against the

WCO standard [Reference

Documents R4] will

widen.

UR IDEN 8 If the “Lodgement” partner cannot process the “Granted”

AEO TIN in its transaction and risk management system, the

partner must:

get the “Granted” AEO TIN from the “Granting” partner

in “Push” mode;

alias the “Granted” AEO TIN with a new TIN that its

systems can process and which must be used by the

“Lodging” trader referring to this AEO. The

“Lodgement” partner is responsible for this aliasing;

store the equivalence “Alias” AEO TIN & “Granted”

AEO TIN to further serve the need of its transaction and

risk management system;

“Push” the equivalence “Alias” AEO TIN & “Granted”

AEO TIN to the “Granting” partner;

maintain its list of “Alias” AEO TIN & “Granted” AEO

TIN synchronised with the update received from the

“Granting” partner (refer to UR BCAS 1 and UR BCAS

3).

This is likely to be the case

for the first IT

implementation of this UB.

UR IDEN 9 The “Granting” partner must inform their AEO of all “Alias”

AEO TINs delivered by the partners, in order to ensure that

the AEO can communicate their alias to the “Lodging” trader


level


2013-04-11 Version 1.20 27


as per UR BCAS 7.

Table 14: TIN

4.3.6.2. Multiple AEO TINs for the same trader


UR IDEN 10 The partners (systems) shall be able to cope with situations

where an AEO has been certified by one or more partners,

but not by themselves.

It is possible that a partner receives records for AEOs that

are not certified in its own AEO program but in those of

other partners.

It is possible that a partner receives records for the same

AEO from more than one partner, each of them referring to

a different TIN (if the economic operator was granted an

AEO status in several partners).

UR IDEN 11 The partners (systems) shall be able to cope with situations

where an AEO has been certified by one or more partners

and also by themselves.

It is possible that a partner receives records for AEOs that

were assigned a TIN by their partners but have also been

registered already under another TIN in its own AEO

program.

Table 15: Multiple TINs

4.3.7. Frequency of data exchange


UR DAEX 1 The AEO data shall be as defined in the SLA. This will allow the same

message structure to

include events such as

suspensions and

revocations which require

an urgent notification.

To support the “Push”

mode.

UR DAEX 2 The data exchange shall take place regularly and according

to an agreed fixed planning.

Data to be exchanged should be made available to all

partners at the same date and time.


mode.

UR DAEX 3 The data extraction, upload, exchange and download shall

not disrupt the availability of the AEO system, the Customs

declaration transaction systems, the risk analysis systems, nor

other relevant systems.


mode.

Table 16: Frequency of data exchange


2013-04-11 Version 1.20 28

4.3.8. Monitoring & statistical requirements


UR STAT 1 The partners must exchange monitoring and statistical

information on the automated process underpinning the

Bilateral AEO MRA to foster continuous improvement.

This should be on a

monthly basis and

exchanged on request.

UR STAT 2 The partners must share their monitoring and statistical

information on automated process underpinning the AEO

MR with the WCO in order to promote the adoption of the

UB.

Table 17: Monitoring & statistical requirements

4.4. Data cluster layer

4.4.1. Functional messages

The messages of the process are:

1. “Granted” AEO from “Granting” partner to other partner, in “Push” or “Pull”

mode.3 The structure of both “Push” and “Pull” messages is defined in Sections

5.1.1.2 and 5.1.3.2;

2. Equivalence “Alias” AEO TIN – “Granted” AEO TIN from “Lodgement” partner

to “Granting” partner, in “Push” mode only. The structure of the message is

defined in Section 5.1.1.3;

3. “Alias” AEO TIN from the “Granting” partner to the AEO: This will not be

further defined in the UB as it falls under the responsibility of the “Granting”

partner;

4. “Granted” AEO TIN or “Alias” AEO TIN from the AEO to the “Lodging” trader:

This will not be further defined in the UB as it falls under the responsibility of the

traders involved;

5. The Customs notification/declaration referring to an AEO from the “Lodging”

trader to the “Lodgement” partner: This will not be further defined in the UB as it

falls under the responsibility of the “Lodgement” partner.

3 While carrying essentially the same “Granted” AEO semantic, the “Push” and “Pull” mode messages

will have substantial differences, the former being batch oriented (multiple “Granted” AEO) while the

latter will be single “Granted” AEO oriented (get info on a single “Granted” AEO). This will be

developed further in the rest of the document. For the sake of simplicity, further reference in the

document to “Granted” AEO message will refer to its “Push” mode version, while “Granted” AEO

“Pull” will refer to its “Pull” mode version.


2013-04-11 Version 1.20 29

4.4.2. Languages and character sets


UR LANG 1 The partners shall be allowed to register the AEO data in

their own language.

For the partners to decide

when specifying the needs

of their particular MRA.

There will be no impact or

requirement on the

exchange system.

UR LANG 2 The data exchanged between partners shall be able to be

processed by the IT systems of the partners. Only commonly

agreed character sets shall be used.

Character sets shall

therefore be agreed.

TIN: see UR IDEN 2

For the other data elements

to be exchanged it is

proposed to use UTF-8.

Table 18: Language and character sets

4.4.3. Data volume


UR VOLU 1 The data exchange systems shall be sized to exchange and

handle as a minimum, the number of created records (+

suspensions, revocations + a margin to cater for some

additional capacity).

When partners are

discussing their MRA, they

need to identify the specific

needs of their particular

MRA, which includes

volumetric details.

Table 19: Data volume

4.5. Trigger layer

The AEO MR process can be supported by three choreography cases between the

involved stakeholders. As indicated in the table hereunder, the choreography case will

depend on the following factors:

The capability of the “Lodgement” partner to process the “Granted” AEO TIN;

Depending on the former, the choice between the “Pull” and Push” Method.


2013-04-11 Version 1.20 30

“Push” mode “Pull” mode

TIN misaligned

between

“Granting” partner and

“Lodgement” partner

(1)

The “Alias” TIN case

The “Granting” partner pushes

the “Granted” AEO TIN to the

“Lodgement” partner;

The “Lodgement” partner

assigns an “Alias” TIN to each

“Granted” AEO and pushes

them to the “Granting” Partner;


validates the “Alias” TIN

submitted in a

notification/declaration against

its local register of “Alias” TIN.

(2) Not Applicable

(3) TIN aligned

between

“Granting” partner and

“Lodgement” partner

(4)

(5)

(6)

The “Granted” AEO & “Push”

case

The “Granting” partner pushes

the “Granted” AEO TIN to

“Lodgement” partner;


validates the “Granted” AEO

TIN submitted in a

notification/declaration against

its local register of “Granted”

AEO TIN

The “Pull” case

The “Granting” partner offers a

web site/service to access its

“Granted” AEO information;


accesses this web site/service,

as required, to check the

“Granted” AEO TIN submitted

in a lodged

notification/declaration.

Table 20: Trigger layer

4.5.1. The “Alias” TIN case

This case corresponds to a situation where a “Lodgement” partner cannot process a

“Granted” AEO TIN in its Customs transaction and risk analysis systems and must

therefore assign an alias to each “Granted” AEO TIN.

This case works on a “Push” mode only.

The “Push” mode allows the “Lodgement” partner to keep the availability of the “Alias”

TIN fully under its control, making it independent of the availability/continuity of the

AEO IT system of the “Granting” partner.

This case represents the most comprehensive choreography to support the AEO MR but

also the heaviest to implement.

This case is mandatory between partners with misaligned TINs.

The Time Sequence Diagram hereunder specifies the messaging choreography between

stakeholders of this case. Please note that the traders are included for completeness

purposes, but that they are out of the scope of the implementation of this UB.


2013-04-11 Version 1.20 31

:"Lodging" Trader:"Lodgement" Partner

Country:"Granting" Partner

Country:AEO Trader

Granting AEO

"Granted" AEO

Assigning Alias TINs to "Granted" AEO

Equivalence "Alias" TIN - "Granted" AEOInforming AEO

about their "Alias" TIN

"Alias" TIN

Notification/Declarationwith "Alias" TIN

Checking AEO "Alias" TIN

Proceeding to Risk Analysis

AEO Status Request

Figure 1: Sequence diagram - “Alias” TIN case


2013-04-11 Version 1.20 32

Figure 2: BPMN2.0 diagram - “Alias” TIN case


2013-04-11 Version 1.20 33

4.5.2. The “Granted” AEO TIN case - “Push” mode

This case corresponds to a situation where a “Lodgement” partner:

(1) can process the “Granted” AEO TIN in its Customs transaction and risk

analysis systems and;

(2) wants to use the “Push” mode to keep the availability of the “Granted” AEO

TIN fully under its control, making it independent of the

availability/continuity of the AEO IT system of the “Granting” partner.

This case is recommended for partners pairs where the “Lodgement” partner

processes high volumes of Customs notifications/declarations.





2013-04-11 Version 1.20 34

:"Lodging" Trader:"Lodgement" Partner Country

:"Granting" Partner

Country

:AEO Trader

Granting AEO

"Granted" AEO

"Granted" AEO

Notification/Declarationwith "Granted" AEO TIN

Checking "Granted" AEO TIN


AEO Status Request

Figure 3: Sequence diagram - “Granted” AEO TIN case - “Push” mode


2013-04-11 Version 1.20 35

Figure 4: BPMN2.0 diagram - “Granted” AEO TIN case - “Push” mode


2013-04-11 Version 1.20 36

This case is the same as the “Alias” TIN case (described under the previous heading) but

without the equivalence messages as they are not required in this case.

4.5.3. The “Granted” AEO TIN case - “Pull” mode

This case corresponds to a situation where a “Lodgement” partner:

(1) can process the “Granted” AEO TIN in its Customs transaction and risk analysis

systems and ;

(2) wishes to consult the “Granting“ partner web service to get the information on the

“Granted” AEO.

The “Lodgement” partner must appreciate that in this case it is entirely dependent for the

availability and continuity of the “Granted” AEO web service of the “Granting” partner.

However, this case offers a low/no cost option for the “Lodgement” partner. The “Pull”

mode, being the leanest mode to implement, is likely to be the case that is the most

scalable to support future UBs.

This case is recommended with low volume of Customs transactions and/or with

limited IT capacity. It is therefore an attractive solution in the context of Capacity

Building.





2013-04-11 Version 1.20 37

:"Lodging" Trader:"Lodgement" Partner

Country:"Granting" Partner

Country:AEO Trader

Granting AEO

"Granted" AEO TIN

Notification/Declarationwith "Granted" AEO TINChecking "Granted" AEO TIN

Checking "Granted" AEO TIN Result


AEO Status Request

Figure 5: Sequence diagram - “Granted” AEO TIN case - “Pull” mode


2013-04-11 Version 1.20 38

Figure 6: BPMN2.0 diagram - “Granted” AEO TIN case - “Pull” mode


2013-04-11 Version 1.20 39

4.5.4. Combination amongst cases

It is important to understand that the 3 cases (see section 4.4) are not mutually exclusive

and will more than likely coexist when underpinning a multilateral AEO MRA.

The cases to be selected for underpinning an AEO MRA will result from the combination

of:

(1) Alignment/misalignment of the AEO TIN structures between the partners

involved;

(2) The wish of “Lodgement” partners to use the “Pull” mode.

It is highly recommended that in all cases, the partners offer at least the following cases

as “Granting” partner:

“Pull” or/and “Push” mode;

“Granted” AEO.

From the above, it is clear that the compliance of all partners of the Bilateral AEO

MRA to the WCO standard regarding the TIN structure is a MAJOR

simplification opportunity in the implementation of this UB and will considerably

reduce the costs and time in implementing the AEO MRA.


2013-04-11 Version 1.20 40

5. IT PROCESS

Codes used for data types and requirements in the message structures are described in

Annex 1. For Business Codes and Data Dictionary refer to Annex 2.1 and Annex 2.2.

5.1. Interface layer

The AEO MRA is implemented in XSD format for both "Push" and "Pull" mode. There

are three XSD schema files as follows:

GNC_AEO_MR_PULL.xsd;

GNC_AEO_MR_PUSH.xsd;

GNC_AEO_Type.xsd.

These schemas use and transfer the same data i.e. AEO data, even though they are split

into three files.

5.1.1. “Alias” TIN case

The technical protocol for the case “Alias” TIN is illustrated in the following figure. The

“Alias” TIN case is relying exclusively on the “Push” mode.


2013-04-11 Version 1.20 41

:"Lodgement" Partner

Country

:"Granting" Partner

Country

"Granted" AEO

Ack

Results

Ack

Equivalence "Alias" TINs - "Granted" AEO TINs

Ack

Results

Ack

Figure 7: Technical protocol for “Push” mode


2013-04-11 Version 1.20 42

Both messages “Granted” AEO and Equivalence Alias” TINs – “Granted” AEO TIN4 are

batch messages (as defined hereafter). The response to each batch message is the Results

message returning the results for each operation in the batch to the sender of the batch. It

contains information about which entries are accepted and which entries are rejected. All

batch and Results messages are acknowledged by the recipient as soon as they are

received.

The acknowledgment message is on protocol level – SOAP response.

5.1.1.1. The batch mechanism

The “Push” mode is based on a batch data replication mechanism. The objective is to

allow the implementation of a fully automated solution that ensures data quality at both

sides.

Each and every batch message will have an identifier which will allow the receiving party

to process the received messages in the correct order.

There are 2 types of batch message exchange based on the same message structure.

Full extraction

A full extraction would contain all available AEO information from the

“Granting” partner. Such a transmission would be exchanged at the beginning

of the exchange process or to synchronise an existing situation.

Differential extraction

A differential message would contain all changes of the AEO information of

the “Granting” partner (new, updated and to-be-deleted records) since the last

successful differential extraction.

The differential message can contain 0 or more individual operations. If there

were no changes to the AEO information since the last successful differential

extraction, then there would be no operations in the message.

Update operations would contain an updated version of all information for the

specified account, not just the individual items to be updated.

The two batch message structures support the data replication mechanism. These

mechanisms are applied in the structure at 3 levels:

Level 1: The header level with the sequence number

Each and every message exchanged should have a sequence number starting

from '000001' for the differential messages which is incremented by 1,

without any gaps in the sequence numbers. This will allow the recipient to

4 Referred to as Equivalence message in the rest of the document


2013-04-11 Version 1.20 43

make sure that no messages are lost at the application level. The initial start-

up message should have the sequence number '000000'.

A synchronisation full extract should have the same sequence number as the

last differential extraction which would indicate to the system that this has

become the new baseline. A full extract shall never contain updates that have

not already been included in differential extractions. The next differential

extraction following that would then have its sequence number incremented

by 1 again to indicate its relation to the (new) current baseline. The following

example illustrates this mechanism:

00000000: full extraction - start up baseline 1

00000001: differential (to baseline 1)

00000002: differential (to baseline 1 + differential 00000001)

00000003: differential (to baseline 1 + differentials 00000001 and

00000002)

00000003: full extraction for baseline 2

00000004: differential (to baseline 2)

Level 2: The message content with the transaction identifier

The transaction identifier allows the sender to group several operations into

one automatic transaction if this is required. However, for the information

exchanges described in this document, it is foreseen to have 1 operation in 1

transaction.

The transaction identifier is unique within the message.

Level 3: Operation

The lowest level is the operation which can be an insert, update or delete of a

given account.


2013-04-11 Version 1.20 44

5.1.1.2. Message “Granted” AEO

The message must be processed according to the following rules:

a) Each transaction will be executed individually within a given Message;

b) The logical key against which an operation will be executed is the AEO TIN;

c) An AEO record that has an Operation =C, but has already a corresponding record

in the IT system of “Lodgement” partner will be rejected;

d) An AEO record that has an Operation = U, but has no corresponding record in

the IT system of the “Lodgement” partner will be rejected;

e) An AEO record that has an Operation = D, but has no corresponding record in

the IT system of the “Lodgement” partner will be rejected;

f) If an AEO record is revoked, then an update operation should occur with the

revoked status;

g) If an AEO record is suspended, then an update operation should occur with the

suspended status.


2013-04-11 Version 1.20 45

GRANTED AEO

MESSAGE HEADER

Version n..2

Sending organisation a2

Receiving organisation a2

Sending date and time dt

Sequence number n8

Extraction type a1

Message identification an36

MESSAGE CONTENT

AEO 999 999 x O

NAME 1 x R

AEO TRADER IDENTIFICATION NUMBER 1 x R

AEO ADDRESS 1 x R

AEO LIFECYCLE 9999 x O

AEO

Transaction identification R an10

Operation R a1

AEO Certificate Type R an1

NAME

Language Code R a2

Full Name R an..300

Short Name R an..35

AEO TRADER IDENTIFICATION NUMBER

According TIN specification of the “Granting” partner, preferably aligned with the WCO TIN

standard [Reference Documents R4]

Country code R a2

Trader National Identifier R an..15

AEO ADDRESS

Street and Number R an..70

Postcode O an..9

City R an..35

Country Sub-entity O an..9

Country Code R a2

AEO LIFECYCLE

Start date R d

End date O d

AEO Certificate Status R a1


2013-04-11 Version 1.20 46

5.1.1.3. Message Equivalence “Alias” TIN – “Granted” AEO TIN

The message must be processed according to the following rules:

a) Each transaction will be executed individually within a given Message;

b) The logical key against which an operation will be executed is the AEO TIN;

c) A “Granted” AEO TIN – “Alias” AEO TIN association record that has an

Operation =C, but has already a corresponding record in the IT systems of the

“Granting” partner will be rejected;

d) A “Granted” AEO TIN – “Alias” AEO TIN association record that has an

Operation = U, but has no corresponding record in the IT system of the

“Granting” partner will be rejected;

e) A “Granted” AEO TIN – “Alias” AEO TIN association record that has an

Operation = D, but has no corresponding record in IT system of the “Granting”

partner will be rejected;

f) If a “Granted” AEO TIN – “Alias” AEO TIN association is revoked, then an

update operation should occur with the revoked status.;

g) If a “Granted” AEO TIN – “Alias” AEO TIN association is suspended, then an

update operation should occur with the suspended status;

h) If the “Alias” AEO TIN is aligned with the WCO TIN standard [Reference Documents

R4] then ALIAS TRADER IDENTIFICATION NUMBER should be used, if it is

misaligned then OTHER TRADER IDENTIFICATION NUMBER must be used.

At least one of both groups must be populated.


2013-04-11 Version 1.20 47

EQUIVALENCE ALIAS TIN – GRANTED AEO TIN

MESSAGE HEADER

Version n..2




Sequence number n8

Extraction type a1


MESSAGE CONTENT

ALIAS AEO – GRANTED AEO ASSOCIATION 999 999 X R

AEO IDENTIFICATION NUMBER 1 x R

ALIAS TRADER IDENTIFICATION NUMBER 1 x O

OTHER TRADER IDENTIFICATION NUMBER 1 x O

ALIAS AEO – GRANTED AEO ASSOCIATION

Transaction identification R an10

Operation R a1

AEO TRADER IDENTIFICATION NUMBER According TIN specification of the “Granting” partner preferably aligned with the WCO TIN

standard [Reference Documents R4]:

Country code R a2


ALIAS TRADER IDENTIFICATION NUMBER According TIN specification of the “Lodgement” partner preferably aligned with the WCO TIN


Country code R a2


OTHER TRADER IDENTIFICATION NUMBER

Other Trader Identification Number O an..256


2013-04-11 Version 1.20 48

5.1.1.4. Results message

The results message serves as the response to a batch message with the processing results

of the message. It is generated by the receiving system for each message received.

Any transaction that was rejected will receive an Accepted=0 indicating that the batch

was rejected.

RESULTS

MESSAGE HEADER

Version n2





Reference Message identification an36

Reference Sequence number n8

Reference Extraction type a1

MESSAGE CONTENT

TRANSACTION 999 999 x R

REMARK 999 x O

TRANSACTION

Transaction Identification R an10

Accepted R n1

REMARK

Status Type R a1

Status Code R an..50

Status Details O an..500


2013-04-11 Version 1.20 49

5.1.1.5. Technical Implementation

Each package will first be validated for XML conformity based on the definition

determined by the XSD.

It is proposed to develop two web services for the implementation of the data exchanges

described in this document. There is only one service for “Push” mode and one service

for “Pull” mode. Each service is designed to accept the messages for the schema with the

relevant namespace. The validation against schemas and the processing of the messages

for both the “Push” mode and the “Pull” mode are to be done independently of the web

service.

5.1.1.5.1. Service inventory

The proposed solution will contain one service provided in one WSDL file for the “Push”

mode.

Service name is “GNCAEOPush”.

Operation “SendMessage” is of type “in” and accepts message with extraction AEO data.

Refer to Annex 3.2.1 for the WSDL –GNCAEOPush.wsdl.

5.1.1.5.2. Service Contract

The operation requires XML messages as parameters. Refer to Annex 3.1 for the XSDs -

GNC_AEO_MR_PUSH.xsd.


2013-04-11 Version 1.20 50

Figure 8: XSD Structure of the “Push” message


2013-04-11 Version 1.20 51

Figure 9: XSD Structure of the “Granted” AEO within the “Push” message


2013-04-11 Version 1.20 52

Figure 10: XSD structure of the Equivalence message


2013-04-11 Version 1.20 53

Figure 11: XSD structure for the Results message

5.1.1.5.3. Error Handling

The following principles will apply:

Schema validation: will be included in the message preparation process and

before processing messages;

Out-of-sequence message: the system should recognise during the message

processing step that the message received is out-of-sequence. In that case, the

system needs to return a Results message with the appropriate error description;

Message that is resent: the system should recognise that the message is being

resent and should raise a duplicate message-id error. In that case, the system needs

to return a Results message with the appropriate error description;

No ACK message received: SOAP level exception should be handled.


2013-04-11 Version 1.20 54

5.1.2. “Granted” AEO TIN case - “Push” mode

In this case, the same technical protocol and the message structure as in the “Alias” TIN

case specified in the previous section (5.1.1 “Alias” TIN) is used. The only difference is

that it will not include the following parts:

Equivalence “Alias” TIN – “Granted” AEO TIN;

Results message.

5.1.3. “Granted” AEO TIN case - “Pull” mode

In the “Pull” mode, the “Lodgement” partner sends the request directly to the “Granting”

partner in order to acquire information for the AEO.

The technical protocol for the case “Pull” mode is illustrated in the following figure:

:"Lodgement" Partner

Country

:"Granting" Partner

Country

1: Request AEO data

2: "Granted" AEO data

return()return()

Figure 12: Technical protocol for “Pull” mode


2013-04-11 Version 1.20 55

When a Request AEO is sent to the "Granting" partner, a "Granted" AEO response is

returned in a matter of seconds in the "Pull" mode.

When an AEO TIN is sent by the "Lodgement" partner, the "Granting" partner will return

the AEO record associated with that TIN number.

In the “Pull” mode, there is one request per AEO TIN which will return one response.

Where multiple TINs need to be checked using the “Pull” mode, multiple requests need

to be sent.

The “Pull” mode access is available through both Web Service and Graphical User

Interface (GUI), and must be made available by the "Granting" partner.


2013-04-11 Version 1.20 56

5.1.3.1. Message Request AEO data

REQUEST AEO DATA

MESSAGE HEADER

Version n..2




MESSAGE CONTENT

AEO REQUEST 1 x R


AEO REQUEST

AEO TRADER IDENTIFICATION NUMBER Country code R a2



2013-04-11 Version 1.20 57

5.1.3.2. Message “Granted” AEO

GRANTED AEO

MESSAGE HEADER

Version n..2




MESSAGE CONTENT

AEO 1 x O

NAME 1 x R


AEO ADDRESS 1 x R

AEO LIFECYCLE 9999 x O

AEO

AEO Certificate Type R an1

NAME

Language Code R a2

Full Name R an..300

Short Name R an..35

AEO TRADER IDENTIFICATION NUMBER

According TIN specification of the “Granting” partner; preferably aligned with the WCO TIN


Country code R a2


AEO ADDRESS

Street and Number R an..70

Postcode O an..9

City R an..35

Country Sub-entity O an..9

Country Code R a2

AEO LIFECYCLE

Start date R d

End date O d

AEO Certificate Status R a1


2013-04-11 Version 1.20 58

5.1.3.3. Technical Implementation

Each package will first be validated for XML conformity based on the definition

determined by the XSD.

One Web Service will be developed for the implementation of the data exchanges

described.

5.1.3.3.1. Service inventory

The proposed solution will contain one service provided in one WSDL file for the “Pull”

mode.

Service name is “GNCAEOPull”.

Operation “SendRequest” is of type “in-out” and accepts request messages and responds

synchronously with a message containing one record of data. Refer to Annex 3.2.2 for the

WSDL: GNCAEOPull.wsdl.

The “Pull” mode realisation will include access to the web page where the user can enter

the TIN of AEO and to get all the conforming information, e.g. certificate type, address

and status lifecycle. The web page will be the front-end representation of the Web

Service.

Here is an example of a GUI using the Web Service.

Figure 13: Sample GUI


2013-04-11 Version 1.20 59

5.1.3.3.2. Service Contract

The operation requires XML message as parameter and returns XML message. Refer to

Annex 3.1 for the XSD - GNC_AEO_MR_PULL.xsd

Figure 14: XSD Structure of the “Pull” message


2013-04-11 Version 1.20 60

Figure 15: XSD Structure of the Request AEO “Pull” message


2013-04-11 Version 1.20 61

Figure 16: XSD Structure of the “Granted” AEO “Pull” message

5.1.3.3.3. Error Handling

The following principles will apply:

- Schema validation: will be included in the message preparation process and before

processing messages;

- Message that is resent: the system should recognise that the message is being

resent and should raise a duplicate message-id error. In that case, the system needs

to return a Results message with the appropriate error description;

- No ACK message received: SOAP level exception should be handled.

All partners must implement the “Granting” partner side of the “Pull” mode to

allow any other partner to easily access their “Granted” AEO.


2013-04-11 Version 1.20 62

5.1.4. Statistics and monitoring

A Statistics and Monitoring data service will be provided via “Pull” mode. The system

maintaining the Web Service should gather statistics and monitor the behaviour of the

various services and make them available to their MRA partner. The results should be

grouped on a monthly basis by UB and sent on request. The request will contain the

month, the year and the UB for which the statistics should be provided. The frequency of

sending of the statistics should be defined in the SLA.

Partner Country Partner Country

return()return()

Request Statistics

Send Statistics

Figure 17: Statistics and monitoring request and response

The following statistic indicators are provided as an example of what can be shared

between partners. In the list below, BP in the “BP01” is an indicator of a Business

statistic type – “Pull” mode and BH in the “BH01” is an indicator of a Business statistic

type – “Push” mode:

BP01 – Count of message requests for UB data received – “Pull” mode;

BP02 – Count of messages with UB data sent – “Pull” mode;

BP03 – Count of requests received through GUI web interface – “Pull” mode;

BH01 – Count of “Granted” AEO send – “Push” mode;

BH02 – Count of AEO “Alias” TINs received – “Push” mode;


2013-04-11 Version 1.20 63

The following monitoring indicators are provided as an example of what can be shared

between partners. In the list below, T in the “T01” is an indicator of a Technical statistic

type.

T01 – Count of service unavailability;

T02 – Count of business exceptions;

T03 – Count of technical exceptions;

T04 – Current availability status.

The schema of the Statistics and Monitoring message is described in Annex 3.1 -

GNC_Statistics_Monitoring_PULL.xsd

The Web Service of the Statistics and Monitoring data exchange is described in Annex

3.2.1 – GNCStatisticsPull, GNC_Statistics_Service_Pull.wsdl

5.2. Communication layer

5.2.1. Networking

The partners will exchange the information on a peer-to-peer network over the internet.

There is no hub, unless otherwise specified.

Each partner will have to adjust their firewall and access management systems in order to

allow the secure exchange of information in compliance with the above requirements.


2013-04-11 Version 1.20 64

5.2.2. Security

5.2.2.1. “Push” mode

Figure 18: Secure “Push” using Web Services


2013-04-11 Version 1.20 65

All messages transmitted between the endpoints of the Web Service shall be encrypted.

There are two levels of encryptions: Channel Level Encryption and Message Level

Encryption:

(1) Channel Level Encryption:

The HTTPS with TLS 1.0 protocols will be used to transport these message

exchanges to secure the communication channel (channel level security). The

partner certificate used on the web service endpoints to provide channel level

security will be issued by any party such as well-known Certificate Authorities

like, Verisign, Entrust, GlobalSign, Thawte, etc.

(2) Message Level Encryption:

The message is encrypted using the following mechanism:

Public key infrastructure (PKI):

Each Web Service endpoint shall use a X.509 version 3 PKI certificate issued

by the WCO acting as authorised Certificate Authority (CA) or any party on

its behalf. Appropriate client and root certificates will be exchanged between

the parties using out-of-band secure channels. These certificates have to be in

place before the actual transmission of data starts.

The key usage must include:

- Key encipherment;

- Data encipherment;

- Digital signature.

The keys used by the RSA algorithm must be 2048-bits long.

SHA-1 will be used as thumbprint (hash) algorithm.

The client certificates for both sides will be valid for one year only and will be

regenerated and exchanged on annual basis.

Symmetric ciphering:

Each Web Service endpoint will support the AES symmetric cipher to encrypt

data payload. The key used by the cipher will be 256-bits long.

Authentication:

Digital signatures will be used to authenticate the source of the message.

Integrity:

Digital signatures of the unencrypted payload will be used to ensure data

integrity.


2013-04-11 Version 1.20 66

5.2.2.2. “Pull” mode

The security principles in “Pull” mode, where the request comes from one partner system

directly to the other partner providing the “Pull” service, are the same as those described

in “Push” mode. The rest of this section details the security principles for accessing the

“Pull” mode service using a graphical user interface (GUI). The GUI is developed and

hosted by the partner providing the “Pull” mode service.

(1) Level 1 – Channel Level Encryption:

HTTPS with GNC security certificate delivered by or on behalf of any authorised party

will be used in cases when using the web interface based on “Pull” mode service.

SSL is designed to establish encryption and identity assurance. It creates an encrypted

link between a web server and a web browser. The link ensures that all data passed

between the web server and browser remains private and secure.

SSL Certificate interaction with the Browser and the Server:

Browser checks the certificate to make sure that the web site is the real site and

not someone intercepting;

Determine encryption types that the browser and web site server can both use to

understand each other;

Browser and Server send each other unique codes to use when encrypting the

information that will be sent;

The browser and server start talking using the encryption, the web browser shows

the encrypting icon, and web pages are processed securely.


2013-04-11 Version 1.20 67

The following figure describes the interaction between the client browser and the web

server.

Figure 19: Secure “Pull” using Web Browser

(2) Level 2 – Data Level Encryption:

Digital signatures5 provided by WCO acting as authorised Certificate Authority (CA) will

be used to authenticate the source of the data. The following steps are performed in order

to check the signature:

The user opens the Web Screen and fills in data for the AEO data request;

The software in the browser generates a hash sum and uses a private key to

encrypt it;

Data are submitted to the server;

5 A digital signature is an electronic signature that can be used to authenticate the identity of the sender of a

document, and possibly to ensure that the original content of the message or document that has been sent is

unchanged. Digital signatures are easily transportable, cannot be imitated by someone else, and can be

automatically time-stamped.


2013-04-11 Version 1.20 68

The software on the server generates hash from the received data and;

Uses public key to decrypt the hash;

If the hashes match, the received data is valid.


2013-04-11 Version 1.20 69

6. GOVERNANCE

6.1. Structure

The partners must document the organisational structure and other instruments that they

intend to rely on to govern the MRA and its Technical Annex, in compliance with the

governance arrangement set in the bilateral AEO MRA.

6.2. Project

6.2.1. Implementation roadmap


2013-04-11 Version 1.20 70

Figure 20: Example of Project plan


2013-04-11 Version 1.20 71

6.2.2. Testing

The integration testing will be performed before the actual deployment of the data

exchange solution. The partners will set up test environments to perform integration

testing.

The integration testing plan and associated test cases will be exchanged between the

partners prior to the commencement of the integration testing.

6.2.2.1. Setup Information for the Test Environment

The information about the test environment endpoints will be exchanged between the

partners prior to the initiation of the integration testing. This information will at

minimum include:

Web Service Node URL;

Web Service Specification;

Root certificates to secure the channel;

PKI certificates to secure the message;

URL testing address for GUI for the “Pull” mode.

The certificates used for securing communication and encrypting messages in testing

environments will be different from the certificates used for production environment.

6.2.2.2. High Level Tests

This chapter briefly describes a number of high level tests that are to be performed during

the integration testing:

Connectivity Testing

This will test if there is connection to the test web server on both ends and the

communication channel is working using HTTPS/TLS protocol.

Message Encryption and Decryption Testing

This will test the use of the PKI certificates to encrypt and decrypt the message, create

digital signature and authenticate the source of the message using the client certificates.

Test Web Service

This will test the actual process of accepting the message payload, processing the payload

and then providing the result of the processing. There will be multiple scenarios covering

the full, differential loads processing along with transaction level test for insert, update

and delete functions. If needed, this will also test the module to associate the “Granted”

AEO TINs and the “Alias” TINs and transmission of such files between partners.


2013-04-11 Version 1.20 72

GUI Test

This will test the actual process of entering TIN data, the search process and the quality

of the returned data. The case with non-available data for the requested TIN should also

be tested.

Performance Test

A performance test is a test whose objective is to determine the performance of a

computer system. The objective of this test is to measure the response time for an

application system based on its solicitation.

Volume testing

Volume testing refers to testing a software application with a certain amount of data.

Stability Tests

The Stability tests determine if an application will crash.

Robust tests

Robustness testing is focused on testing the robustness of software. Robustness testing

has also been used to describe the process of verifying the robustness (i.e. correctness) of

test cases in a test process and if the application can function correctly in the presence of

invalid inputs or stressful environmental conditions.

6.3. Operational Level Agreement

6.3.1. Frequency

The exchanges could be scheduled at regular intervals and the frequency should be

agreed upon by both parties.

6.3.2. Availability

6.3.2.1. Partner x Availability example

The service at partner x side is determined as non-critical and will be offered in full

support on weekdays during office hours (GMT+x hours). Outside these periods, the

service should still be available to be used, but there would be limited support.

Business Days: From Monday to Friday, except 25/12 and 01/01,

irrespective of any official or national holidays.

Business Hours: 07:00 – 20:00 GMT+x hours of any partner x Business

Day.

Availability:


2013-04-11 Version 1.20 73

outside partner x business hours

target on annual basis 97.0 %

limit on monthly, quarterly and annual basis 94.5 %

within partner x business hours

target on annual basis 99.0 %

limit on monthly, quarterly and annual basis 97.0 %

Mean Time To Repair (in partner x business hours):

target on annual basis: 4 hours

limit on monthly, quarterly and annual basis: 6 hours

6.3.2.2. Partner y Availability example

The partner y considers that the receiving of “Granted” AEO and sending back the

equivalence “Alias” TIN- “Granted” AEO TIN as non-critical. The service is available

24 hours a day, 7 days a week, with the exception of the scheduled maintenance and

deployment windows. Interruptions to service and/or availability will be addressed

during normal business hours of partner y.

Partner y Business Days: From Monday to Friday

Partner y Business Hours: 08:00 – 18:00 GMT+y hours of any partner

y Business Day.

6.3.3. Troubleshooting

(1) When an error occurs, the Support Team of the system which identified the error

will perform the initial investigation of the issue;

(2) The Support Team will notify their respective Program Office with details of the

identified error and identify the course of action to resolve or continue the

investigation;

(3) If the Development Team requires consultation from counterparts in the partners,

the Development Team will request the Program Office to initiate contact with the

partner to begin joint investigations;

(4) Resolutions that require configuration or development changes will be escalated

to the Program Office for authority to initiate a change process.

6.3.4. Help-Desk

6.3.4.1. Partner x example

IT Requests and issues should be addressed to the ITSM Service-Desk. The Service-Desk

is available from 7:00 to 20:00 GMT+x hours Monday to Friday except 1st of January

and 25th of December.

Contact details:


2013-04-11 Version 1.20 74

Telephone +xxxxxxxxxx

Fax +xxxxxxxxxx

E-mail [email protected]

6.3.4.2. Partner y example

IT Requests and issues should be addressed to the partner y Support Team. The partner y

Support Team is available from 08:00 – 18:00 GMT+y hours Monday to Friday.

Contact details:

E-mail: [email protected]

6.4. Change Management

Changes to this document require coordination between both programs. To facilitate this,

a Change Management Board (CMB) should be established with representatives from all

partners.

Any party within either program (e.g. leadership, technical staff, internally within the

CMB, etc.) can submit change requests (CR) to the CMB. The CMB will evaluate each

CR and identify those that will be included in the next revision of the technical annex of

the MRA Technical Annex (MRA TA).

The CMB will revise the MRA TA (this may include the technical staff) and, if

necessary, submit the proposed TA to other parties for review and comments. This

review is necessary even if the proposed changes are not expected to affect other parties

(e.g. technical staff, etc.). The CMB should define a finite (but reasonable) timeframe for

this review. After the review the CMB will make any appropriate changes to the

proposed TA.

After finalization of the proposed TA, the CMB will request a preliminary level of effort

from each system’s technical staff. The CMB will submit the proposed TA to the

leadership of both programs for approval.

After approval, the CMB will work with both programs to schedule the work effort for

each system’s technical staff and identify two key dates. The first date identifies the start

of a transition period when both systems have implemented the changes and are ready to

accept and transmit message packages according to the newly approved TA, but will still

accept packages from the previous TA. This transition period is often necessary to

accommodate those packages that have already been sent but have not yet been

processed. The second date identifies the end of the transition period, when either system

may completely remove support for the previous TA. If a transition period is not

necessary then the two key dates will be the same date.


2013-04-11 Version 1.20 75

7. INTEGRATION LAYER (TO BE FILLED IN BY THE PARTNERS)

The examples provided in this section are purely informative and refer to the EU

experience and knowledge coming from the different agreements or on-going

negotiations.

7.1. Business case partners interaction

The BPM below illustrates the interactions between partners within the AEO MR process

and places it within the process ecosystems of both the “Granting” partner and

“Lodgement” partner.


2013-04-11 Version 1.20 76

Figure 21: AEO MR Business process and its integration in the partners' Customs processes –“Push” mode


2013-04-11 Version 1.20 77

Figure 22: AEO MR Business process and its integration in the partners' Customs processes – “Pull” mode


2013-04-11 Version 1.20 78

7.2. Business case national profiling

Identifier User

requirement

Remarks

UR BCAS 4 The exchange shall

be for economic

operators holding

AEO certificates

only.

EU: The exchange is for AEO security and safety certificates (Art.

14a 1b CCIP) and combined Customs simplification/security and

safety certificates (Art. 14a 1c CCIP).

US: C-TPAT members at level 2 & 3 should be accepted. It is not

necessary to distinguish between level 2 and level 3 C-TPAT AEOs.

The benefits to be granted by the partners are the same.

China/Japan all certified AEOs.

CH: All certified AEOs

NO: All certified AEOs

CA: All certified PIPs

Table 21: Business case national profiling

7.3. AEO identification national provisions

The following table shows the national provisions used to identify AEOs in the respective

potential partners. The purpose of this table is to illustrate the alignment and

compatibility of the different national provisions with the WCO data model [Reference

Documents R4].

Country Trader Identification Number Example Aligned with

WCO Format

China Format an..17

The 'Customs registration code' with the

country pre-fix 'CN' shall be used.

CN5007931102

Yes

EU Format an..17

The EORI number (Economic Operator

Registration and Identification) shall be

used. It consists of:

Identifier of the country that issued

the TIN a2

National unique number an..15

PL1234567890ABCDE Yes

Norway Format an..17

The TIN with the country pre-fix 'NO'

shall be used.

Norway adds its country code as prefix to

TINs for its NCTS traders. Hence, the

structure of NO TINs corresponds to that

of EU EORI. However, TINs for NO

NCTS traders are based on traders

organisation number (VAT-numbers)

maintained in a national central traders

register. The same register is also used

for NO AEOs.

NO1234566789

Yes

Japan Format an..17

The “Customs unique ID No.” with the

country pre-fix 'JP' shall be used.

For information: in Japan 2 numbers

JP123456x7890

Yes


2013-04-11 Version 1.20 79

Country Trader Identification Number Example Aligned with

WCO Format

exist:

First one is “JASTRO Number” which is

provided by “JASTRO: Japan

Association for Simplification of

International Trade Procedures” based on

request from exporters and/or importers

including AEO. “JASTPRO No” is

“P00＋9 digits of Unique Number” ex.

P00123456789 (in total 12 digits)

Second one is “Customs unique ID No.”

which is provided by Japan Customs

based on request from exporters and/or

importers including AEO. “Customs

unique ID No.” is “12 digits of Number

and/or alphabet” ex. 123456x78900 (in

total 12 digits).

In Japan, exporters and/or importers

including AEO can use either of the

numbers on their import/export

declaration. Both numbers include “AEO

status” so that the Japanese Customs

clearance IT System (NACCS) can

identify AEO status automatically.

Switzerland Format an..17

The TIN with the country pre-fix 'CH'

shall be used.

CH1234 Yes

US Format an..17

The C-TPAT number with the country

pre-fix 'US' shall be used.

USaplsea00888 Yes

Table 22: AEO identification national provisions

7.4. Security


UR SECU 1 The data exchange between partners shall be secured, the

information and the information system shall be

protected from unauthorised access, use, disclosure,

disruption, modification or destruction

The technical means to secure

the data exchange shall be

agreed on technical level.

Data will be exchanged at EU

level. No data exchange is

envisaged at MS level.

Table 23: Security

7.5. Availability of exchanged data

7.5.1. Availability of exchanged data to the Customs transaction systems

(declaration systems)



2013-04-11 Version 1.20 80


UR AVRI 1 The exchanged AEO data is expected to be used in the

context of the (online) validation of declarations for goods

entering or leaving the Customs territory (including transit).

The exchanged data shall therefore be up-to-date and highly

available. An availability of 99% (7x24) should be

envisaged.

It must be recognised that

the partners are located in

various time zones. An

availability concept based

on opening hours or

working hours, considering

weekends and public

holidays can therefore not

be envisaged.

Table 24: Availability to the Customs transaction systems

7.5.2. Availability of exchanged data to the risk management


UR AVRI 2 The exchanged AEO data is expected to be used in the

context of the (online) risk assessments and the targeting of

declarations for goods entering or leaving the Customs

territory.

The exchanged data shall therefore be up-to-date and highly

available. An availability of 99% (7x24) should be

envisaged.

It must be recognised that

the partners are located in

various time zones. An

availability concept based

on opening hours or

working hours, considering

weekends and public

holidays can therefore not

be envisaged.

Table 25: Availability to the risk management

7.5.3. Availability of exchanged data to trade operators


UR AVTO 1 Where national rules are provided, the partner granting the

AEO status may publish their AEO data in the appropriate

manner and to the appropriate economic operators.

UR AVTO 2 Partners shall not publish AEO data received from other

partners.

Table 26: Availability to trade operators

7.6. Data volume

Following number of created AEO records are estimated (excluding suspensions and

revocations):

Partner # of “Granted” AEO # of Lodgement referring to AEO

Table 27: Data volume


2013-04-11 Version 1.20 81

7.7. Compliance


UR CONS 3 In cases according to UR BCAS 5 and UR BCAS 6

(unilateral suspension/revocation of benefits for all or

selected AEOs of a partner) the granting partner shall be

allowed to re-assess the AEO status and, if necessary, to

update the status of the relevant AEO records in accordance

with UR BCAS 3 (AEO status suspended, revoked,

suspension annulled or revocation annulled).

Relevant for the EU only:

On the level of the EU, it

shall be for the Commission

to identify unilateral

suspensions and

revocations in accordance

with UR BCAS 5 and UR

BCAS 6.

A specific user role shall be

created for this purpose.

Such suspension and

revocation decided and

recorded in the EOS by the

Commission shall be

applicable for all EU

Member States.

Table 28: Compliance

7.8. IT Architecture


UR ITA 1 Partners are recommended to verify the AEO TIN from the

data received from their MRA partner (either by using the

“Pull” or “Push” mode) directly from their Automated

Customs Systems and Risk Analysis systems.

UR ITA2 For the “Pull” mode partners should:

Provide a web service for receiving requests for AEO

data;

Obtain a digital certificate by WCO authority;

Register the partner users and share certificates between

partners;

Provide a web user interface for receiving requests and

sending responses with AEO data;

Set up monitoring and statistics collection, and provide a

service for partners to query this data;

Provide a service client to connect to the other countries

“Pull” services.

UR ITA3 For the “Push” mode partners should:

Provide a web service for receiving result messages;

Provide a service client to call a partner web service and

send data;

Obtain a digital certificate by WCO authority;

Register partner and exchange certificates;

Set up monitoring and statistics collection, and provide a

service for partners to query this data.

Table 29: IT Architecture


2013-04-11 Version 1.20 82

7.9. Infrastructure


UR INFR 1 The decision of the technical infrastructure for the exchange

of AEO data on the level of the partners shall be made by the

partners.

UR INFR 2 The technical infrastructure shall support the business

processes, the security and the availability requirements

identified in this document.

Table 30: Infrastructure


2013-04-11 Version 1.20 83

8. CAPACITY BUILDING

All partners should implement their role of “Granting” partner at least as a web interface

and web service. This will allow the “Lodgement” partners to use the “Pull” mode for

direct consultation by their Customs officials or automatically by their Customs IT

systems at low cost. This will offer a first low-cost entry point into GNC to all

“Lodgement” partners.

In the future, the above specification could also be implemented to build the AEO MR

capacity at lower cost and minimal change for a partner with limited IT capacity in the

following ways:

Provision of a lite hub6 allowing a “Lodgement” partner to access via a single web

site, all the “Granting” partner web sites in “Pull” mode, easing its management of

access;

Implementation of the role of “Lodgement” partner and “Granting” partner by any

technology provider using specified software;

Provision of the role of “Lodgement” partner and “Granting” partner in a fat hub7

provided by one of the partners to other partners in the AEO MR.

Those three last options call for additional investment by a 3rd

partner and/or organisation

which may or may not be part of the specifications. The AEO MR must define the

financial arrangement underpinning the provision of these services.

6 Quoted from the IT Strawman version 2.0 GNC Ad Hoc Group April 2011: The lite “hubs” will mainly

orchestrate all information flows involved in the exchange/sharing of information between the

Members connected to it and other peer hubs or distributed peers. They will act as GNC automated

post offices. The hubs will neither host trade nor exit information but may well store non sensitive

reference information. It is suggested to consider one GNC lite hub per WCO region (6 worldwide).

[… ]The Members hosting the regional hubs will have to support the Members which want to connect

to it (the “Spoke” Members) in establishing and keeping their connectivity up (hub operation). The

regional lite hubs would offer to their Spoke Members the traffic management and reporting service to

the WCO central monitoring and statistic applications”.

7 Quoted from the IT Strawman version 2.0 GNC Ad Hoc Group April 2011: The “fat hub builds up

incrementally on the lite hub to offer in addition the processing of all trade and transaction information

in the hub database plus the necessary supporting IT services for Risk Management. The “fat hubs”

would offer to their Members the traffic management and reporting service to the WCO central

monitoring and statistic applications. The Members hosting the fat hubs will have to support their

Spoke Members in establishing and keeping their connectivity up (fat hub operation). This will save

the “Spoke” Members to implement their interface to GNC and national Risk Management system. It

will however keep the automation of Customs processes at national level. The Members opting for this

option as “Spoke” will therefore reduce their investment costs but will need to pay for GNC as a

service to compensate for the costs incurred by the fat hub member. […] It could go until the fat hub

offering remotely a complete automated Customs system to the spoke Members. There may be one or

several GNC fat hubs. […] The consolidation of the GNC IT operation by a core of Members with

high mutual trust into a common GNC fat hub, […] will call for an adequate financial model

(engineering) to support the sustainability of this consolidated operation.”


2013-04-11 Version 1.20 84

ANNEX 1: CODES USED FOR DATA TYPES AND REQUIREMENTS IN THE MESSAGE STRUCTURES

Code name Format Domain values; remarks

Data Type Acronyms a = Alpha

n = Numeric

d = Date (W3 XML date type with time zone in UTC)

dt = Date Time (W3 XML date time type with time zone in UTC)

Data Requirement Acronyms R = Required

O = Optional

Data Type and Length Example:

R an..300

First letter indicates the Data Requirement

Second set of letters indicates the Data Type

An ellipsis (..) indicates a length greater than or equal to 0 but less than or equal to the following number

The number indicates the max length of the data element

Table 31: Codes used for data types and requirements


2013-04-11 Version 1.20 85

ANNEX 2: BUSINESS CODES AND DATA DICTIONARY

ANNEX 2.1: BUSINESS CODES

Code name Format Length Domain values; remarks

Operation a 1 C = Create

U = Update

D = Delete

AEO certificate status a 1 Values:

C = Current

S = Suspended

R = Revoked

AEO Certificate Type an 1 Certificate types:

To be defined by the partners

Accepted n 1 Values:

0 = Rejected

1 = Accepted

Country Code

a 2 Code to specify countries (ISO alpha 2 country code as specified in ISO – 3166).

Language Code a 2 Language Code (LNG) used to define the language used for declaration purposes and for

free text information (ISO Alpha 2 Codification – ISO 639).

Table 32: Business codes


2013-04-11 Version 1.20 86

ANNEX 2.2: DATA DICTIONARY

Code name Definition Format Length Domain values; remarks

Accepted The status of AEO data record in Result

message

n 1 Values:

0 = Rejected

1 = Accepted

AEO certificate status Code to distinguish between current,

suspended and revoked certificates.

a 1 Values:

C = Current

S = Suspended

R = Revoked

AEO Certificate Type The type of AEO certificate an 1 Certificate types:

To be defined by the partners

AEO TIN

Unique identifier for the authorised

economic operator allocated by the

“Granting” partner and linked to the relevant

AEO certificate.

an 17 “Granted” AEO trader Identification assigned by the “Granting”

partner

“ALIAS” TIN “Alias” TIN assigned by the „Lodgement“

partner to any “Granted” AEO TIN in case

the „Lodgement“ partner cannot process the

“Granted” AEO TIN assigned by the

“Granting” partner.

an 17 “Alias” TIN assigned by a „Lodgement“ partner to a “Granted”

AEO TIN

City City name of the AEO. an 35

Country Subentity Additional code an 9

Country Code Code to specify countries. a 2 ISO alpha 2 country code as specified in ISO – 3166.

Data Requirement Acronyms R = Required

O = Optional

Data Type Acronyms a = Alpha

n = Numeric

d = Date (W3 XML date type with time zone in UTC)

dt = Date Time (W3 XML dateTime type with time zone in UTC)

Data Type and Length Example:

R an..300

First letter indicates the Data Requirement

Second set of letters indicates the Data Type

an ellipsis (...) indicates a length greater than or equal to 0 but less

than or equal to the following number

The number indicates the max length of the data element


2013-04-11 Version 1.20 87


End date It is the end date of the validity period of the

AEO TIN. Together with the Start Date data

item, it provides the full picture of the

validity that the AEO TIN may have during

its lifecycle.

d Defines the date at which the AEO certificate status ceases to be

applicable.

Together with the Start Date item, it defines the period during

which the AEO certificate status is applicable. If the end date is

empty the validity period is 'open ended'.

W3 XML date standard with time zone. Format (yyyy-mm-dd)

UTC Date.

Extraction Type The type of the extraction performed a 1 Values:

F = Full

D = Differential

Full name Full name of the AEO. an 300

Language Code Language code identifying the

language/character set.

a 2 Language Code used to define the language used for all textual

information

(ISO Alpha 2 Codification – ISO 639).

Message identification Unique message identifier an 36 Identifier created using GUID algorithm

Operation Code to distinguish between created,

updated and deleted records.

a 1 Values:

C = Create

U = Update

D = Delete

Other TIN Nationally defined Identity Number an 256 Used in the cases the country partner has Identity Number not

compliant with WCO Data Model [Reference Documents R4]

Postcode Postal code of the AEO. an 9

Receiving organisation ISO – 3166 alpha country code for the

partner receiving the record.

a

2 For records sent to the US CBP system the code 'US' shall be used

For records sent to the EU system the code 'EU' shall be used

ISO – 3166

Reference Extraction Type The type of the extraction performed in

Equivalence message

a 1 Values:

F = Full

D = Differential

Reference Message identification Unique response message identifier an 36 Unique message identifier using GUID algorithm

Reference Sequence number Result message number n 8 Identifies the Result message sequence

Status Details Description of the details of the status an 500 Free text up to 500 characters with status details

Sending date and time Date when the record is sent dt

Date and timestamp when the record is sent

W3 XML dateTime standard with time zone (yyyy-mm-

ddThh:mi:ss.ssZ) in UTC


2013-04-11 Version 1.20 88


Sending organisation ISO – 3166 alpha 2 country code for the

partner sending the record.

a 2 For records sent by the EU system the code 'EU' shall be used

For records sent by the US CBP system the code 'US' shall be used

ISO – 3166

Sequence number Identifies data exchanges as result of

extraction

n

8 If this is a full extraction of data, the sequence number corresponds

to the sequence number of the encompassed differential extraction.

For the initial startup message, it is ‘00000000’.

Short name Short name of the AEO. an 35 Short name of the AEO limited to the maximum of 35 characters

that are provided for in the WCO data model [0.6].

Start date It is used to define the starting date of the

validity period of an AEO TIN.

Together with the End Date item, it provides

the full picture of the validity of a particular

value that the described item may have

during its lifecycle.

d Defines the date from which the AEO certificate status is

applicable.

Together with the End Date item, it defines the period during which

the AEO certificate status is applicable.

W3 XML date standard with time zone. Format (yyyy-mm-ddZ)

UTC Date

Status Code Codes for specific scenarios

an

50

Values:

E00001 = Failed to insert, record already exists

E00002 = Failed to update, record does not exist

W00003 = Failed to delete, record does not exist

I10001 = Record updated, but not changes included

Status Type Identifies the type of status information.

a

1

Values:

‘E’ = Error

‘W’ = Warning

‘I’ = Information Only

Street and number Street and number of the AEO. an 70

Trader National Identifier Unique identifier for the authorised

economic operator allocated by the

competent authority and linked to the

relevant AEO certificate

an 15

Transaction identification Technical element allowing to group several

operations into one atomic transaction

an 10

Version Technical element to indicate the version of

the message structure

n 2


2013-04-11 Version 1.20 89

Table 33: Data Dictionary


2013-04-11 Version 1.20 90

ANNEX 3: XSD AND WSDL

ANNEX 3.1: XSD

ANNEX 3.1.1: AEO MESSAGES XSD

GNC_AEO_MR_PUSH.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="urn:GNC_AEO_MR:1.0" xmlns:gnc="urn:GNC_AEO_MR:1.0" xmlns:tin="urn:publicid:wco:gnc:tintype:1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:st="urn:publicid:wco:gnc:simpletypes:1.0" xmlns:ns1="urn:GNC_AEO_MR:1.0" xmlns:aeo="urn:publicid:wco:gnc:aeotype:1.0" targetNamespace="urn:GNC_AEO_MR:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:import namespace="urn:publicid:wco:gnc:aeotype:1.0" schemaLocation="GNC_AEO_Type.xsd"/> <xs:import namespace="urn:publicid:wco:gnc:tintype:1.0" schemaLocation="GNC_TIN_Type.xsd"/> <xs:import namespace="urn:publicid:wco:gnc:simpletypes:1.0" schemaLocation="GNC_Simple_Types.xsd"/> <xs:complexType name="AEOieType"> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:element name="SequenceNumber" type="SequenceNumberType"/> <xs:element name="ExtractionType" type="ExtractionTypeType"/> <xs:element name="MessageID" type="st:GUID"/> <xs:element name="AEO" type="AEOTypePush" minOccurs="0" maxOccurs="999999"/> </xs:sequence> </xs:complexType> <xs:complexType name="ResultType"> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:element name="MessageID" type="st:GUID"/>


2013-04-11 Version 1.20 91

<xs:element name="ReferenceMessageID" type="st:GUID"/> <xs:element name="ReferenceSequenceNumber" type="SequenceNumberType"/> <xs:element name="ReferenceExtractionType" type="ExtractionTypeType"/> <xs:element name="Transaction" maxOccurs="999999"> <xs:complexType> <xs:sequence> <xs:element name="TransactionID" type="st:TransactionIDType"/> <xs:element name="Accepted" type="xs:boolean"/> <xs:element name="Remark" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="StatusType" type="ResultStatusType"/> <xs:element name="StatusCode" type="ResultStatusCodeType" minOccurs="0"/> <xs:element name="StatusDetail" type="StatusDetailType" minOccurs="0"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:element name="Envelope"> <xs:complexType> <xs:choice> <xs:element name="AEOie" type="AEOieType"> <xs:unique name="AEOieTransactionKey"> <xs:selector xpath="./gnc:AEO"/> <xs:field xpath="gnc:TransactionID"/> </xs:unique> </xs:element> <xs:element name="EquivalenceID" type="EquivalenceIDType"> <xs:unique name="EquivalenceIDTransactionKey"> <xs:selector xpath="./gnc:AEO"/> <xs:field xpath="gnc:TransactionID"/> </xs:unique> </xs:element>


2013-04-11 Version 1.20 92

<xs:element name="Result" type="ResultType"> <xs:unique name="ResultTransactionKey"> <xs:selector xpath="./gnc:Transaction"/> <xs:field xpath="gnc:TransactionID"/> </xs:unique> </xs:element> </xs:choice> </xs:complexType> </xs:element> <xs:complexType name="EquivalenceIDType"> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:element name="SequenceNumber" type="SequenceNumberType"/> <xs:element name="ExtractionType" type="ExtractionTypeType"/> <xs:element name="MessageID" type="st:GUID"/> <xs:element name="AEO" type="EquivalenceIDAEOType" maxOccurs="999"/> </xs:sequence> </xs:complexType> <xs:complexType name="EquivalenceIDAEOType"> <xs:sequence> <xs:element name="TransactionID" type="st:TransactionIDType"/> <xs:element name="Operation" type="st:OperationType"/> <xs:element name="TIN" type="tin:TINType"/> <xs:choice> <xs:element name="EID" type="tin:TINType" minOccurs="0" maxOccurs="unbounded"/> <xs:element name="MEID" type="xs:string"/> </xs:choice> </xs:sequence> </xs:complexType> <xs:simpleType name="ResultStatusCodeType"> <xs:restriction base="xs:string"> <xs:enumeration value="E00001"/> <xs:enumeration value="E00002"/> <xs:enumeration value="W00003"/>


2013-04-11 Version 1.20 93

<xs:enumeration value="I10001"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="ResultStatusType"> <xs:restriction base="xs:string"> <xs:enumeration value="E"/> <xs:enumeration value="W"/> <xs:enumeration value="I"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="ExtractionTypeType"> <xs:restriction base="xs:string"> <xs:enumeration value="F"/> <xs:enumeration value="D"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="SequenceNumberType"> <xs:restriction base="xs:string"> <xs:pattern value="\d{8}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="StatusDetailType"> <xs:restriction base="xs:string"> <xs:minLength value="0"/> <xs:maxLength value="500"/> </xs:restriction> </xs:simpleType> <xs:complexType name="AEOTypePush"> <xs:complexContent> <xs:extension base="aeo:AEOType"> <xs:sequence> <xs:element name="TransactionID" type="st:TransactionIDType"/> <xs:element name="Operation" type="st:OperationType"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType>


2013-04-11 Version 1.20 94

</xs:schema>


2013-04-11 Version 1.20 95

GNC_AEO_MR_PULL.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="urn:GNC_AEO_MR:1.0" xmlns:icd="urn:GNC_AEO_MR:1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns1="urn:GNC_AEO_MR" xmlns:aeo="urn:publicid:wco:gnc:aeotype:1.0" xmlns:st="urn:publicid:wco:gnc:simpletypes:1.0" xmlns:tin="urn:publicid:wco:gnc:tintype:1.0" targetNamespace="urn:GNC_AEO_MR:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:import namespace="urn:publicid:wco:gnc:aeotype:1.0" schemaLocation="GNC_AEO_Type.xsd"/> <xs:import namespace="urn:publicid:wco:gnc:tintype:1.0" schemaLocation="GNC_TIN_Type.xsd"/> <xs:import namespace="urn:publicid:wco:gnc:simpletypes:1.0" schemaLocation="GNC_Simple_Types.xsd"/> <xs:complexType name="AEOieType"> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:element name="AEO" type="aeo:AEOType"/> </xs:sequence> </xs:complexType> <xs:element name="Envelope"> <xs:complexType> <xs:choice> <xs:element name="AEOie" type="AEOieType" minOccurs="0"/> <xs:element name="AEORequest" type="AEORequestType"/> </xs:choice> </xs:complexType> </xs:element> <xs:complexType name="AEORequestType"> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:element name="TIN" type="tin:TINType"/> </xs:sequence> </xs:complexType>


2013-04-11 Version 1.20 96

</xs:schema>


2013-04-11 Version 1.20 97

GNC_AEO_TYPE.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:aeo="urn:publicid:wco:gnc:aeotype:1.0" xmlns:tin="urn:publicid:wco:gnc:tintype:1.0" xmlns:st="urn:publicid:wco:gnc:simpletypes:1.0" targetNamespace="urn:publicid:wco:gnc:aeotype:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="urn:publicid:wco:gnc:tintype:1.0" schemaLocation="GNC_TIN_Type.xsd"/> <xs:import namespace="urn:publicid:wco:gnc:simpletypes:1.0" schemaLocation="GNC_Simple_Types.xsd"/> <xs:complexType name="AEOType"> <xs:sequence> <xs:element name="CertificateType" type="aeo:AEOCertificateTypeType"/> <xs:element name="Name"> <xs:complexType> <xs:sequence> <xs:element name="LanguageCode" type="st:LanguageCodeType"/> <xs:element name="FullName" type="aeo:FullNameType"/> <xs:element name="ShortName" type="aeo:ShortNameType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="TIN" type="tin:TINType"/> <xs:element name="Address"> <xs:complexType> <xs:sequence> <xs:element name="StreetAndNumber"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="70"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="Postcode" minOccurs="0"> <xs:simpleType> <xs:restriction base="st:SingleLineString"> <xs:minLength value="1"/>


2013-04-11 Version 1.20 98

<xs:maxLength value="9"/> <xs:pattern value="\p{IsBasicLatin}+"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="City"> <xs:simpleType> <xs:restriction base="st:SingleLineString"> <xs:minLength value="1"/> <xs:maxLength value="35"/> </xs:restriction> </xs:simpleType> </xs:element>

<xs:element name="CountrySubCode" type="st:CountrySubCodeType" minOccurs="0"/> <xs:element name="CountryCode" type="st:CountryCodeType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="LifecycleEvent" minOccurs="0" maxOccurs="9999"> <xs:complexType> <xs:sequence> <xs:element name="StartDate" type="xs:date"/> <xs:element name="EndDate" type="xs:date" minOccurs="0"/> <xs:element name="CertificateStatus" type="aeo:CertificateStatusType"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> <xs:simpleType name="AEOCertificateTypeType"> <xs:restriction base="xs:string"> <xs:length value="1"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CertificateStatusType"> <xs:restriction base="xs:string"> <xs:enumeration value="C"/>


2013-04-11 Version 1.20 99

<xs:enumeration value="S"/> <xs:enumeration value="R"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="FullNameType"> <xs:restriction base="st:SingleLineString"> <xs:minLength value="1"/> <xs:maxLength value="300"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="ShortNameType"> <xs:restriction base="st:SingleLineString"> <xs:minLength value="1"/> <xs:maxLength value="35"/> </xs:restriction> </xs:simpleType> </xs:schema>


2013-04-11 Version 1.20 100

GNC_Simple_Types.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:st="urn:publicid:wco:gnc:simpletypes:data:1.0" xmlns:ns1="urn:publicid:wco:gnc:simpletypes:1.0" targetNamespace="urn:publicid:wco:gnc:simpletypes:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:simpleType name="OrganizationType"> <xs:restriction base="xs:string"> <xs:length value="2"/> <xs:pattern value="[A-Z][A-Z]"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="VersionType"> <xs:restriction base="xs:integer"> <xs:totalDigits value="2"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="SingleLineString"> <xs:restriction base="xs:string"> <xs:pattern value="[^\n\r]*"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="CountryCodeType"> <xs:restriction base="xs:string"> <xs:length value="2"/> <xs:pattern value="[A-Z][A-Z]"/> </xs:restriction> </xs:simpleType>

<xs:simpleType name="CountrySubCodeType"> <xs:restriction base="xs:string"> <xs:maxLength value="9"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="LanguageCodeType"> <xs:restriction base="xs:string">


2013-04-11 Version 1.20 101

<xs:length value="2"/> <xs:pattern value="[A-Z][A-Z]"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="GUID"> <xs:restriction base="xs:string"> <xs:pattern value="([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12})|(\{[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}\})"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="TransactionIDType"> <xs:restriction base="xs:string"> <xs:pattern value="\d{10}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="OperationType"> <xs:restriction base="xs:string"> <xs:enumeration value="C"/> <xs:enumeration value="U"/> <xs:enumeration value="D"/> </xs:restriction> </xs:simpleType> </xs:schema>


2013-04-11 Version 1.20 102

GNC_TIN_Type.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:tin="urn:publicid:wco:gnc:tintype:1.0" xmlns:st="urn:publicid:wco:gnc:simpletypes:1.0" targetNamespace="urn:publicid:wco:gnc:tintype:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="urn:publicid:wco:gnc:simpletypes:1.0" schemaLocation="GNC_Simple_Types.xsd"/> <xs:complexType name="TINType"> <xs:sequence> <xs:element name="CountryCode" type="st:CountryCodeType"/> <xs:element name="TNI" type="tin:TNIType"/> </xs:sequence> </xs:complexType> <xs:simpleType name="TNIType"> <xs:restriction base="st:SingleLineString"> <xs:minLength value="1"/> <xs:maxLength value="15"/> <xs:pattern value="\p{IsBasicLatin}+"/> </xs:restriction> </xs:simpleType> </xs:schema>


2013-04-11 Version 1.20 103

GNC_Statistics_Monitoring_PULL.xsd

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns="urn:GNC_STAISTICS:1.0" xmlns:gnc="urn:GNC_STAISTICS:1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ns1="urn:GNC_STAISTICS:1.0" xmlns:st="urn:publicid:wco:gnc:simpletypes:1.0" targetNamespace="urn:GNC_STAISTICS:1.0" elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0"> <xs:import namespace="urn:publicid:wco:gnc:simpletypes:1.0" schemaLocation="GNC_Simple_Types.xsd"/> <xs:element name="Envelope"> <xs:complexType> <xs:sequence> <xs:element name="Version" type="st:VersionType" fixed="1"/> <xs:element name="SendingOrganization" type="st:OrganizationType"/> <xs:element name="ReceivingOrganization" type="st:OrganizationType"/> <xs:element name="SendingDateTime" type="xs:dateTime"/> <xs:choice> <xs:element name="StatisticsResponse" type="StatisticsResponseType"/> <xs:element name="StatisticsRequest" type="StatisticsRequestType"/> </xs:choice> </xs:sequence> </xs:complexType> </xs:element> <xs:complexType name="StatisticsRequestType"> <xs:sequence> <xs:element name="month" type="monthType"/> <xs:element name="year" type="yearType"/> <xs:element name="UB" type="UBType"/> </xs:sequence> </xs:complexType> <xs:complexType name="StatisticsResponseType"> <xs:sequence> <xs:element name="stattype" type="statTypeType"/> <xs:element name="statvalue" type="statValueType"/> <xs:element name="UB" type="UBType"/> </xs:sequence> </xs:complexType>


2013-04-11 Version 1.20 104

<xs:simpleType name="monthType"> <xs:restriction base="xs:string"> <xs:pattern value="\d{2}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="yearType"> <xs:restriction base="xs:string"> <xs:pattern value="\d{4}"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="UBType"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="statValueType"> <xs:restriction base="xs:integer"/> </xs:simpleType> <xs:simpleType name="statTypeType"> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:schema>


2013-04-11 Version 1.20 105

ANNEX 3.2 WSDL

ANNEX 3.2.1: GNCAEOPush

GNC_AEO_Service_Push .wsdl

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="urn:publicid:wco:gnc:aeo:1.0" targetNamespace="urn:publicid:wco:gnc:aeo:1.0"> <wsdl:message name="ExtractionMessage"> <wsdl:part name="In"/> </wsdl:message> <wsdl:portType name="SendMessagePortType"> <wsdl:operation name="SendMessage" parameterOrder="In"> <wsdl:input name="ExtractionMessage" message="tns:ExtractionMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="bindUB" type="tns:SendMessagePortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="SendMessage"> <soap:operation soapAction="urn:SendMessage"/> <wsdl:input name="ExtractionMessage"> <soap:body use="literal"/> </wsdl:input> </wsdl:operation> </wsdl:binding> <wsdl:service name="GNCAEOPush"> <wsdl:port name="SendMessagePort" binding="tns:bindUB"> <soap:address location="http://localhost:8080/AEODataPush"/> </wsdl:port> </wsdl:service> </wsdl:definitions>


2013-04-11 Version 1.20 106

ANNEX 3.2.2: GNCAEOPull

GNC_AEO_Service_Pull .wsdl

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="urn:publicid:wco:gnc:aeo:1.0" targetNamespace="urn:publicid:wco:gnc:aeo:1.0"> <wsdl:types> <xs:schema targetNamespace="urn:publicid:wco:gnc:aeo:1.0"> </xs:schema> </wsdl:types> <wsdl:message name="RequestMessage"> <wsdl:part name="In"/> </wsdl:message> <wsdl:message name="ResponseMessage"> <wsdl:part name="Out"/> </wsdl:message> <wsdl:portType name="SendRequestPortType"> <wsdl:operation name="SendRequest" parameterOrder="In"> <wsdl:input name="RequestMessage" message="tns:RequestMessage"/> <wsdl:output name="ResponseMessage" message="tns:ResponseMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="bindUB" type="tns:SendRequestPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="SendRequest"> <soap:operation soapAction="urn:SendRequest"/> <wsdl:input name="RequestMessage"> </wsdl:input> <soap:body use="literal"/> <wsdl:output name="ResponseMessage"> <soap:body use="literal"/> </wsdl:output> </wsdl:operation>


2013-04-11 Version 1.20 107

</wsdl:binding> <wsdl:service name="GNCAEOPull"> <wsdl:port name="SendMessagePort" binding="tns:bindUB"> <soap:address location="http://localhost:8080/AEODataPull"/> </wsdl:port> </wsdl:service> </wsdl:definitions>


2013-04-11 Version 1.20 108

ANNEX 3.2.3: GNCStatisticsPull

GNC_Statistics_Service_Pull.wsdl

<?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:http="http://schemas.xmlsoap.org/wsdl/http/" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:tns="urn:publicid:wco:gnc:statistics:1.0" targetNamespace="urn:publicid:wco:gnc:statistics:1.0"> <wsdl:types> <xs:schema targetNamespace="urn:publicid:wco:gnc:statistics:1.0"> </xs:schema> </wsdl:types> <wsdl:message name="RequestMessage"> <wsdl:part name="In"/> </wsdl:message> <wsdl:message name="ResponseMessage"> <wsdl:part name="Out"/> </wsdl:message> <wsdl:portType name="SendRequestPortType"> <wsdl:operation name="SendRequest" parameterOrder="In"> <wsdl:input name="RequestMessage" message="tns:RequestMessage"/> <wsdl:output name="ResponseMessage" message="tns:ResponseMessage"/> </wsdl:operation> </wsdl:portType> <wsdl:binding name="bindUB" type="tns:SendRequestPortType"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <wsdl:operation name="SendRequest"> <soap:operation soapAction="urn:SendRequest"/> <wsdl:input name="RequestMessage"> </wsdl:input> <soap:body use="literal"/> <wsdl:output name="ResponseMessage"> <soap:body use="literal"/> </wsdl:output>


2013-04-11 Version 1.20 109

</wsdl:operation> </wsdl:binding> <wsdl:service name="GNCStatisticsPull"> <wsdl:port name="SendMessagePort" binding="tns:bindUB"> <soap:address location="http://localhost:8080/StatisticsPull"/> </wsdl:port> </wsdl:service> </wsdl:definitions>