Technology for Open International Trade Electronic Trade Scenarios PART II

1. Erasmus University P.O. Box 1738 3000 DR Rotterdam, The Netherlands tel. 31 (10) 408 26 01 fax 31 (10) 453 13 21 www.euridis.fbk.eur.nl/Euridis/ Ronald M. Lee email R.Lee@fac.fbk.eur.nl EURIDIS Erasmus University Research Institute for Decision and Information Systems Technology forOpen International TradeElectronic Trade ScenariosPART II

2. Scenario Representation Automated Auditing: Audit Daemons Automated Generation: Scenario Grammars Distributed Regulations: Messenger Model Outline

3. Scenario Representation Documentary Petri Nets

4. different node types = agency of choice (endogenous, exogenous) Graphical Representations: Abstract: State Transition Diagrams Applied: DecisionTrees nodes = states arcs = transitions

5. arcs = activities, tasks (sub-states) nodes = transitions total state of system = set of active tasks Graphical Representations: Abstract: Marked Graphs Applied: PERT Diagrams install bath do plumbing do electrical finish walls

6. Combines: choice, contingency (STN) concurrency (marked graph) Graphical Representations: Abstract: Petri Nets circle nodes = places (sub-states) bar nodes = transitions tokens = mark active places

7. circles = control nodes boxes = document nodes cube = physical goods bar = action triangle = decision node Graphical Representations: from Buyer: purchase_order Seller: decide_accept Applied: Documentary Petri Nets {accept_order} {reject_order} null Seller: deliver_goods Seller: send_invoice to Buyer: [goods] to Buyer: [invoice]

8. Auditing Scenarios Audit Daemons

9. Doing tasks -- get the job done efficiently Control tasks -- ensure agents have sufficient authority for task agents do not exceed/misuse their authority Auditing = verify adequacy of controls under control over control Designing Business Procedures

10. identify where control tasks are needed proper authority for control task input requirements: documentary evidence of doing task other info available to doing task output: evidence that control was performed Control Task Requirements Detective: examine evidence of doing tasks after their effect Preventive: verification of doing task prior to its effect

11. Formal representation of procedures enables computer analysis ... Audit daemons = pattern-matching rules for documentary petri nets (DPN’s Basic syntax: if <conditions> warning <text> because <text>. Audit Daemons

12. Example ... (from Bons, 1997, p. 170-188) • WARNING: • Someone should testify the • completion of the primary activity • send_doc(the_sea_carrier, • transport_instruction( • the_consignee, Goods)) • of the_shipper otherwise • the_shipper, is not able • to prove that it executed • its obligation.

13. Extract from audits rule base ... • /*-------------------------------------------------------------------------*/ • /* audit daemon rule */ • /*-------------------------------------------------------------------------*/ • 'Audit Rule Ia' :: • if core_activity(Role1, PA, A1) and • not testify(Role1, Role2, Role1, PA, IP, A2) • warning [ • ‘Someone should testify the completion of the primary activity’, PA, • ‘of’, Role1, ‘otherwise’, Role1, • ‘is not able to prove that it executed its obligation.’ • ]. • /*-------------------------------------------------------------------------*/ • /* testify */ • /*-------------------------------------------------------------------------*/ • testify(Role1, Role3, Role2, PA, IP, A1) if • testify_table(Role2, PA, IP, Role3) and • not equal(Role2, Role3) and • not socially_close(Role2, Role3) and • witness(Role3, Role2, PA, A2) and • issue_ip(Role3, IP, A4) and • match(follow(Role3, A3, Role3, A4)) and • match(dpn_receive_ip(Role1, RoleX, IP, A1)).

14. Uses: * somewhat useful for auditing manual procedures * main purpose: design and development of electronic procedures * audit rules/patterns as a means of distributing control policy in procedure development Concluding Remarks For more information see: Bons, Roger W.H. Designing Trustworthy Trade Procedures for Open Electronic Commerce PhD Dissertation, Euridis and Faculty of Business, Erasmus University, September, 1997.

15. Automated Generation Of Control Procedures Scenario Grammars

16. Re-usability of control knowledge Trade scenario consists of: Doing tasks -- depend on goals of contracting parties Control tasks -- depend on: * level of trust among parties * requirements of legal system * available communication technologies Would like to automate expertise of designing control tasks: * input: set of doing tasks * output: electronic trade scenario (DPN’s) System asks for additional parameters, as needed. Goal: re-usability of control knowledge * encapsulate control aspects in re-usable ‘chunks’

17. Consist of: * chain pattern -- recognize patterns of doing tasks * scenario grammar rules -- (linear) * scenario grammar templates -- (graphical) -- role grammar templates -- linked, multi-role templates Scenario Grammars

18. chain_pattern prepaid_sale :: if link(money, buyer(B), seller(S)), link(goods, seller(S), buyer(B)) then [S,B]: prepaid_sale. chain_pattern postpaid_sale :: if link(goods, seller(S), buyer(B)), link(money, buyer(B), seller(S)) then [S,B]: postpaid_sale. Example Chain Patterns

19. scenario_grammar [Buyer, Seller]: prepaid_sale ==> [Buyer, Seller]: payment(money(@amount, @currency)) ++ [Seller, Buyer]: send_docs([pay_receipt(@amount, @currency)]) ++ [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Seller]: send_docs([goods_receipt(@kind, @id)]); end. scenario_grammar [Buyer, Seller]: postpaid_sale ==> [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Seller]: send_docs([goods_receipt(@kind, @id)]) ++ [Buyer, Seller]: payment(money(@amount, @currency)) ++ [Seller, Buyer]: send_docs([pay_receipt(@amount, @currency)]); end. Notes: Variables (beginning with Capital letter) are resolved at scenario generation; Parameters (@<parm>) are resolved at scenario execution time. Example Scenario Rules

20. [X,Y]: payment(Money)==> Money X: send_payment Y: recv_payment [X, Y]: delivery(Goods) ==> Goods X: deliver_goods Y: recv_goods [X, Y]: send_doclist(Docs) ==> Docs X: send_docs Y: recv_docs Example Templates (as Linked DPN’s)

21. seller_jones buyer_smith goods(horse, 'Molly') money(200, euro) Example 1: Chain Diagram (PostPay)

22. $ goods(horse, 'Molly') seller_jones: deliver_goods buyer_smith: recv_goods [goods_receipt(horse, 'Molly')] seller_jones: recv_docs buyer_smith: send_docs money(200, euro) seller_jones: recv_payment buyer_smith: send_payment [pay_receipt(200, euro)] seller_jones: send_docs buyer_smith: recv_docs PostPay Example 1: Result Scenario (as Linked DPN)

23. seller_philips bank_abn buyer_fiat money(5000, euro) goods(headlites, 10000) money(5000, euro) Example 2: Chain Diagram (Escrow)

24. $ $ money(5000, euro) [escrow_advice(5000, euro)] bank_abn: recv_payment buyer_fiat: send_payment seller_philips: recv_docs bank_abn: send_docs goods(headlite, 10000) buyer_fiat: recv_goods seller_philips: deliver_goods [escrow_release] bank_abn: recv_docs buyer_fiat: send_docs seller_philips: recv_payment bank_abn: send_payment Escrow Example 2: Result Scenario (as Linked DPN)

25. chain_pattern escrow_sale :: if link(money, buyer(B), bank(K)), link(goods, seller(S), buyer(B)) link(money, bank(K), seller(S)), then [S,K,B]: escrow_sale(S,K,B). scenario_grammar [Buyer, Bank, Seller]: escrow_sale(S,K,B) ==> [Buyer, Bank]: payment(money(@amount, @currency)) ++ [Bank, Seller]: send_docs([escrow_advice(@amount, @currency)]) ++ [Seller, Buyer]: delivery(goods(@kind, @id) ++ [Buyer, Bank]: send_docs([escrow_release(@kind, @id)]) ++ [Bank, Buyer]: payment(money(@amount, @currency)); end. Example 2. RuleBase (Excerpt)

26. Consignee Carrier Shipper Goods Goods Example 3: Steveadore as TTP

27. Chain Pattern: chain_pattern steveadore_as_ttp :: if link(goods, shipper(S), carrier(T)), link(goods, carrier(T), consignee(C)) then [Shipper, Steveadore1, Carrier, Steveadore2, Consignee]: steveadore_as_ttp(Goods, bill_lading, title_doc). Scenario Grammar: [Shipper, Steveadore1, Carrier, Steveadore2, Consignee]: steveadore_as_ttp(Goods, bill_lading, title_doc) ==> [Shipper, Steveadore1, Carrier]: dispatch_and_receipt(Goods, [bill_lading]) ++ [Carrier]: transport_goods(Goods) ++ [Carrier, Steveadore2, Consignee]: dispatch_and_receipt(Goods, [title_doc]) ; end. Note: this scenario grammar demonstrates re-usability of templates Example 3:RuleBase

28. [Sender,Receiver,TTP]: dispatch_and_receipt(Goods, DocList) ==> Sender: send_goods Receiver: send_docs TTP: transfer Receiver: recv_goods Sender: recv_docs Example 3: Template

29. Goods [bill_lading] [arrival_notice] Consignee: recv_docs Shipper: send_goods Carrier: send_docs Carrier: send_docs Steveadore1: transfer [title_doc] Goods Consignee: send_docs Carrier: recv_goods Shipper: recv_docs Carrier: send_goods [bill_lading] Goods Steveadore2: transfer Carrier: transport_goods Carrier: recv_goods Carrier: recv_docs Goods [bill_lading] steveadore_as_ttp Example 3: Result Scenario (as Linked DPN)

30. Consignee Carrier IssueBank Shipper CorresBank Goods Money Money Money Goods Example 4: Documentary Credit

31. Example 4. Scenario Grammar • [ Shipper, Consignee, IssueBank, CorresBank, Carrier ] : documentary_credit() ==> • ShipDocs = [ bill_lading, commerc_invoice, gsp_a] • A :: • { Consignee, Shipper]: send_docs([purchase_order]) << • [Shipper, Consignee]: send_docs([p_o_acknowledgement]) << • [Consignee, IssueBank]: send_docs([lc_request]) << • [IssueBank, Consignee, CorresBank]: send_docs([lc]) • } • /* concurrency */ • B :: • { CorresBank, Shipper]: send_docs([lc]) << • [ Shipper, Carrier]: dispatch_goods([Goods]) << • [ Carrier, Shipper]: send_docs ([bill_lading]) << • [Shipper, CorresBank ]: send_docs(ShipDocs) << • [CorresBank, IssueBank, Shipper]: eval_lc(ShipDocs) • } • C :: • { Carrier, Consignee ]: send_docs ([arrival_notice]) << • [Consignee, IssueBank]: send_docs([money]) << • [IssueBank, Consignee]: send_docs(ShipDocs) << • [Carrier, Consignee ]: phys_transfer ([Goods]) • } • A << B, A << C.

32. [CorresBank, IssueBank, Shipper]: eval_lc(ShipDocs) ==> • [CorresBank, IssueBank, Shipper]: corres_bank_eval_lc(ShipDocs); • [IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs); • [Shipper, CorresBank]: shipper_receive_eval_lc(ShipDocs); • end. Example 4: Rulebase (continued)

33. [X, Y, Z]: send_doclist_2party(DocList) ==> DocList Y: recv_docs X: send_docs DocList Z: recv_docs Example 4: Template

34. [IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs) ==> From CorresBank: ShipDocs IssueBank: recv_docs =reject =accept IssueBank: send_docs IssueBank: send_payment to CorresBank: money(Amt, Curr) to CorresBank: [rejection_notify | ShipDocs] Example 4: RoleTemplate, IssueBank

35. [Shipper, CorresBank]: shipper_receive_eval_lc(ShipDocs) ==> from CorresBank: [rejection_notify | ShipDocs] from CorresBank: money(Amt, Curr) Shipper: recv Shipper: recv =end =end Example 4: Role Template, Shipper

36. [IssueBank, CorresBank]: issue_bank_eval_lc(ShipDocs, Money) ==> =accept =reject CorresBank: send_docs CorresBank: send_docs to Shipper: [rejection_notify | ShipDocs] to IssueBank: ShipDocs CorresBank: recv_docs CorresBank: recv_payment from IssueBank: [rejection_notify | ShipDocs] =end to Shipper: [rejection_notify | ShipDocs] CorresBank: send_payment to Shipper: Money =end Example 4:Role Template, CorresBank

37. Example 4: ResultingDocumentary Credit Scenario(as before)

38. Messenger Model NavigatingDistributedRegulations

39. Transactions constrained by regulations by foreign governmental agencies * e.g. import/export duties * e.g. trade boycotts, embargos * e.g. dangerous goods regulations * Subject to change by agency * Must be checked before doing the transaction * Note: centralized copies may be out of date. approach: Messenger Model ... automated agents heuristic search regimes (formalized regulations) Challenge

40. Regime = way of doing business (rules, procedures) Inbox = performative communications Database = performative record Back Office Front Office Information System Queries Regime Illocutions Out Illocutions In Database Inbox Anatomy of a digital agency (or company):

41. messenger can search the environment -- the marketplace (shopping messengers) -- bureaucratic requirements messenger makes deliveries -- of messages -- of other information objects e.g. audio, video recordings; e.g. books, articles e.g. software -- of promisory objects e.g. titles e.g. licenses messenger can collect (same things) messenger has limited signature authority (performative function) What can a messenger do?

42. Search of a messenger is based on referrals These are addresses of further regimes to search Referrals obtained by ... suggestions of a regime e.g. bureaucracy e.g. vendor collected sources e.g. shopping mall e.g. yellow pages Referral of messengers Note: referrals implemented on Web as URL's

43. A. Navigation and discovery among requirements the client does not know what is required, and has some difficulty in finding out; in nasty cases, the standard solution is somehow frustrated; an alternative must be found. Sometimes, this is discovering flexibility within the requirements (e.g. fax, official copy); other times, it might be navigating around the bureaucracy (e.g. via alternate route). B. Transaction execution once a solution path is found, one actually performs the transaction. Two main aspects of the problem

44. Query messenger: manual queries -- user interacts with regime automated queries -- messenger pursues goal Transaction messengers -- execute the transaction Modes of operation Front Office Query Messenger Regime Transaction Messenger Inbox

45. Example Scenario: SOVAM Teleport * first commerical data communications company in Russia, starting in 1986 * began as a joint venture with American company, San Francisco Teleport * now, clients include SWIFT, major banks, international news agencies, etc. * CEO: Vladimir Teremetsky 1992: * decided to expand their satellite communications was necessary * negotiated a favorable deal with NORCO, a company in Anchorage, Alaska * item: 6 meter satellite dish * payment as a documentary credit * transport: by ship from Anchorage to Vladivostok by rail Vladivostok to Moscow Vladimir recounts the experience as a "labyrinth of bureaucracy". In addition to the usual trade documents, additional requirements were imposed from both the export (US) and import (RU) side. The US has long maintained a prohibition against export of technology to the USSR that has potential military importance. Even though the USSR had officially ended, the policy was still partially in force.

46. Norco to US-Customs: request proc (export) NORCO US Customs Office Request for procedure: export military goods

47. Norco to DOD: request proc (miliary goods) DOD Office of Export Controls NORCO Norco to US-Customs: request proc (export) US Customs Office Request for procedure: export military goods

48. Norco to DOD Telecomm: request proc (inspection) DOD Military Telecomm NORCO Norco to DOD: request proc (miliary goods) DOD Office of Export Controls Norco to US-Customs: request proc (export) US Customs Office Request for procedure: export military goods

49. DOD Telecom Office Nordco Request Non-military Certification NorCo: request cert DOD Telecom: certify specs Non-military Certification DOD Export Controls NorCo: dispatch goods NorCo to DOD Export Controls: Physical Inspection Goods Inspection Report Generated Procedure NORCO US Customs Customs Release

50. SOVAM Sovam to Rus Trade Office: request proc (import) Russia Trade Office Request for procedure: import of telecomm