Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a banking-communication-swift
Semelhante a banking-communication-swift (20)
Mais de PwC Belgium
Último
Último (20)
banking-communication-swift
- 1. Banking communication PWC: Treasury hot topics conference Elie Lasker Head of Corporate market – SWIFT Thursday: 24 Feb 2011
- 2. 2 Agenda Corporates on SWIFT – status update Bank certification programme Additional services PWC - 24 February 2011
- 3. Breakdown by region and annual revenues Total: 726 # corporates <500M 500M-1B Emergence of mid’ market adoption in EMEA PWC - 24 February 2011 3
- 4. Typical implementation FIN (individual messages)Payments (MT101), statements (MT940/2) and FX confirmations (MT3xx) SWIFTNet FileAct (File transfer)Transport any format; payments files, iDOC, ISO 20022, ACHs, BAI formats, … Treasury Workstation Paymentfactory/middleware ERP(s) ERP(s) ERP Connectivity PWC - 24 February 2011 4
- 5. Distribution of connectivity per corporate size 5 Annual turnover PWC - 24 February 2011
- 6. 6 Agenda Corporates on SWIFT – status update Bank certification programme Additional services PWC - 24 February 2011
- 7. Bank readiness certification programme: background Reason Early 2010 bank and corporatesurveyresults Goal Increasebanks' (operational and commercial) readinessstatus Increasevisibility of banks' readinessstatustowardscorporates Scope Operational: correct offer of essential message standards availability of documentation efficient support during roll-out Commercial: availability of collateral qualified sales force 7 PWC - 24 February 2011
- 8. Bank readinesswebsite PWC - 24 February 2011 8
- 9. 9 Agenda Corporates on SWIFT – status update Bank certification programme Additional services PWC - 24 February 2011
- 10. Treasury deals confirmations and SWIFT AccordCentral Matching Service Deal 1 FIN MT 3xx MT 3xx Corporate Broker / Dealer Copies of confirmations Real-time interactive Reporting and Exception handling 2 4 Accord Confirmation Matching 3 10 PWC - 24 February 2011
- 11. SWIFT flows FIN MT798 SWIFT flows FileAct SWIFT flows FIN MT7xx Any format Any format MT798s MT798s 1 2 3 Seller Buyer Buyer’s bank(s) Seller’s bank(s) FIN MT7xx 1 Buyer sends Application for a Letter of Credit to its bank either via FIN (MT798) or via FileAct (eg, other format) 2 Buyer’s bank extracts the appropriate data from the incoming Application flows (eg, MT798), putting them into an Issue of Letter of Credit and sends them to the seller’s bank over FIN (eg, MT700) 3 Seller’s bank forwards the MT700 to the Seller as an Advice of Letter of Credit using FIN (MT798) or FileAct (eg, other format) Trade for Corporates 11 PWC - 24 February 2011
- 14. Multi-Network
- 15. Multi-CountryNo uniform mechanism Different system per bank Costly & difficult to maintain PWC - 24 February 2011
- 17. Automated/STP
- 18. Slow
- 19. Low integration
- 20. Faster/cheaper
- 21. Standardised
- 22. Expensive
- 23. Low satisfaction13 PWC - 24 February 2011
- 24. The EBAM Central Utility - being investigated 14 Banks Corporates EBAM central utility Administrator database app-to-appmessaging Bank and countryrequirements database Messaging and validation module GUI SWIFTNet browsing Internet Key features and benefitsCentral Utility validates XML instructions, incl. bank and country specific implementations Banks offer a single “source of truth” for bank/country requirements, to vendors and customers Corporates offer an "administrators database", with the legal representatives of an organisation A GUI allows to manually initiate EBAM transactions Access through SWIFTNet and/or internet Registration and access control is 3SKey-based PWC - 24 February 2011
- 25. BPO: new inter-bank instrument in support of Open Account services PWC - 24 February 2011 Physical presentation of compliant documents Electronic presentation of compliant data 15
- 26. Q&A ? 16 PWC - 24 February 2011
Notas do Editor
- In practice, banks and their corporate clients must often manage and use multiple and different types of personal signing mechanisms (for example, multiple tokens or smartcards with different passwords). Using and maintaining different authentication methods in parallel adds to the complexity and leads to higher operational risk and cost.