Streszczenie
Celem artykułu jest przybliĪenie znaczenia zastosowania systemów informatycz-nych, w tym w szczególnoĞci narzĊdzi klasy EDI, do wspomagania działalnoĞci ban-ków związanej z obsługą transakcji handlowych miĊdzy kooperantami znajdującymi siĊ z róĪnych krajach. Artukuł opisuje podstawowe zasady trade finance oraz rolĊ systemów informatycznych w realizacji czynnoĞci związanych z finansowaniem han-dlu. W opisie funkcjonowania systemów, szczególną rolĊ przypisano elektronicznej wymianie danych, jako podstawowemu medium wymiany informacji miĊdzy bankami stron przedsiĊwziĊcia oraz miĊdzy bankami i ich klientami.
Słowa kluczowe: Trade finance, EDI, akredytywy, inkasa, gwarancje, Swift 1. Wprowadzenie
Trade Finance – finansowanie handlu, jest instrumentem finansowym oferowanym przez ban-ki, podmiotom instytucjonalnym, bdcym ich klientami. Rola trade finance polega na wspomaga-niu przez banki realizacji transakcji handlowych lub usługowych poprzez obsług procesów zwizanych z przekazywaniem dokumentów handlowych i/lub finansowaniem przedsiwzi midzy podmiotami gospodarczymi.
Na trade finance składaj si dwie grupy instrumentów: operacje dokumentowe oraz gwaran-cje bankowe.
1. Operacje dokumentowe to akredytywy i inkasa dokumentowe. Zadaniem banków jest zorganizowanie przesyłu i kontroli dokumentów handlowych midzy stronami a take dokonanie rozliczenia transakcji handlowej/usługowej, na podstawie przedstawionych dokumentów.
2. Gwarancja bankowa jest form zabezpieczenia transakcji handlowej/usługowej przez bank na rzecz jednej ze stron transakcji.
Akredytywa dokumentowa oraz gwarancja stanowi zobowizanie banku. Inkaso dokumen-towe takim zobowizaniem nie jest.
W dalszej czci opracowania opisano przebieg podstawowych procesów trade finance oraz rol systemów informatycznych w ich automatyzacji a take zastosowanie EDI w tych procesach.
2. Procesy w Trade Finance Operacje dokumentowe
Operacje dokumentowe składaj si z podobnych procesów, std zaklasyfikowane zostały do jednej grupy instrumentów finansowych. Jak wspomniano wczeniej, na instrumenty te składaj si inkasa dokumentowe i akredytywy dokumentowe.
Schemat akredytywy/inkasa = OH F H Q LH R WZ D UF LD D N UH G \ W\ Z \ 3 U] \ MĊ F LH ] D E H ] S LH F ] H Ĕ = D Z D UF LH X P R Z \ $ Z L] R Z D Q LH D N UH G \ W\ Z \ D = D S áD WD 3 U] H N D ] D Q LH G R N X P H Q Wy Z E = D S áD WD ' R N X P H Q W\
Rys. 1. Schemat działania akredytywy dokumentowe ródło: Opracowanie własne.
Akredytywa dokumentowa ma na celu wspomoenie przez banki importera i eksportera ope-racji zwizanych z przekazaniem towaru oraz zapłat za towar. Usługa ta pozwala stronom kon-traktu na przeprowadzenie procesu handlowego zgodnie z wymogami handlu midzynarodowego oraz stanowi zabezpieczenie, dla obu stron, prawidłowego wykonania transakcji i jej rozliczenia.
Jak wida na powyszym rysunku, w realizacji akredytywy dokumentowej, udział bior czte-ry strony:
• Zleceniodawca akredytywy – importer (kupujcy) • Beneficjent akredytywy – eksporter (sprzedajcy)
• Bank importera – bank, obsługujcy akredytyw od strony importera
• Bank eksportera (bank poredniczcy) – bank obsługujcy akredytyw od strony ekspor-tera.
Najogólniej ujmujc proces akredytywy dokumentowej przebiega w sposób nastpujcy: Na bazie kontraktu (1.), zawartego midzy kupujcym a sprzedajcym, kupujcy (importer) zwraca si do swojego banku (banku importera) z wnioskiem o otwarcie akredytywy dokumento-wej (3.). Na podstawie wniosku, po przeprowadzeniu poprawnej weryfikacji, bank importera otwiera akredytyw dokumentow, rejestrujc odpowiednie limity. Informacja o otwartej
akredy-tywie przesyłana jest do banku eksportera (3.). Na podstawie informacji o otwarciu akredytywy, bank eksportera dokonuje zarejestrowania akredytywy i jej awizacji (przedstawienia) eksporterowi (4.).
Zarejestrowana akredytywa jest podstaw do wysłania przez eksportera towarów, bdcych przedmiotem transakcji handlowej (5.). Towar z reguły nie trafia bezporednio do importera, gdy, aby go odebra , importer musi by w posiadaniu dokumentów przewozowo-spedycyjnych. Doku-menty te przekazane zostaje przez eksportera do swojego banku (6.), za nastpnie przez bank eksportera, wraz z tzw. listem przewodnim (wykazem dokumentów) do banku importera (7.). W banku importera dokumenty podlegaj kontroli pod wzgldem zgodnoci z warunkami akredy-tywy. W sytuacji, gdy dokumenty s niezgodne bank prezentuje je importerowi, który moe zgodzi si na realizacj akredytywy (dokonanie zapłaty za towar), na podstawie dokumentów niezgodnych. Jeeli dokumenty s zgodne lub importer wyraził zgod na realizacj akredytywy, dokonywana jest płatno za transakcj. Płatno dokonuje najpierw importer na rzecz banku importera (8a.) za nastpnie bank importera do banku eksportera na rzecz eksportera (8.). Bank eksportera po otrzymaniu zapłaty, przekazuj j eksporterowi (8b.). Po dokonaniu płatnoci, bank importera przesyła importerowi oryginały dokumentów (9.), które s podstaw do odbioru towaru przez importera.
Procesy zwizane z obsługa inkas dokumentowych
Poniszy rysunek prezentuje schemat działania inkasa. Inkaso jest generalnie instrumentem podobnym do akredytywy. Główne rónice polegaj na tym, i w inkasie stron inicjujc proces jest eksporter oraz to, e aden z banków (importera i eksportera) nie musi traktowa inkasa jako zobowizania. Fakt ten wpływa na brak funkcji gwarancyjnych tego instrumentu.
Schemat działania inkasa
Rys. 2. Schemat działania inkasa ródło: Opracowanie własne.
Gwarancje
Gwarancje s instrumentem finansowym, mogcym stanowi zabezpieczenie pod zakup towa-rów, wykonanie towaru lub usługi, spłaty zadłuenia i innych czynnoci. Gwarancja bankowa stanowi zobowizanie banku do wykonania wiadczenia zapłaty na rzecz beneficjenta gwarancji, gdy spełnione zostan wszystkie warunki gwarancji. W konsekwencji oznacza to, e bank dokona realizacji gwarancji (wypłaty rodków z tytułu gwarancji), w sytuacji, gdy beneficjent gwarancji zgłosi si do banku z wnioskiem o jej realizacj, pod warunkiem oczywicie, e bd spełnione inne warunki realizacji gwarancji. Przykładowo gwarancja moe dotyczy zapłaty za zakup towarów. Beneficjentem gwarancji bdzie sprzedajcy towar, za sama gwarancja bdzie zabez-pieczeniem zapłaty za towar. W sytuacji, gdy kupujcy dokona zapłaty za towar własnymi rod-kami, gwarancja automatycznie zostanie zamknita. Jeeli jednak kupujcy nie dokona zapłaty za towar, sprzedajcy moe zada od banku realizacji gwarancji i w efekcie wypłaty rodków z gwarancji na rzecz sprzedajcego. Gwarancja zrealizowana staje si automatycznie wymagaln nalenoci banku od kupujcego.
Przebieg gwarancji jest nastpujcy: wnioskodawca zwraca si do banku o otwarcie gwarancji (czsto najpierw otwierana jest linia gwarancyjna, w ramach której bank udziela kolejnych gwa-rancji, do wysokoci okrelonego limitu. Limit z reguły jest odnawialny, co oznacza, e zakocze-nie jednej z gwarancji, zawartych w ramach linii, zwiksza dostpny limit o wielko gwarancji zakoczonej). Bank rozpatruje wniosek i po przyjciu odpowiednich zabezpiecze, dokonuje rejestracji gwarancji. Informacja o otwartej gwarancji wysyłana jest do beneficjenta gwarancji. Jeeli beneficjent gwarancji nie zwróci si do banku z wnioskiem o realizacj gwarancji, wyganie ona po terminie wanoci. Zgłoszenie przez beneficjenta wniosku o realizacj gwarancji powoduje wypłat rodków z tytułu gwarancji i realizacj zabezpiecze. Gwarancja zrealizowana staje si wymagaln nalenoci banku, w stosunku do wnioskodawcy. Dalsze czynnoci podejmowane przez bank zwizane s z procesami windykacyjnymi. Majcymi na celu odzyskanie nalenoci.
3. Zastosowanie systemów informatycznych w procesach trade finance
Zastosowanie systemów informatycznych w realizacji procesów zwizanych z trade finance ma ogromne znaczenie. W tym punkcie opracowania wskazano najwaniejsze aspekty informaty-zacji operacji finansowania handlu.
Podział systemów informatycznych trade finance
Mona dokona podziału systemów informatycznych trade finance, co najmniej pod wzgl-dem dwóch kryteriów:
• Uytkowników systemu, do których jest dedykowany • Rodzaju produktu oraz roli klienta w procesie
Zgodnie z pierwszym kryterium, systemy te mona podzieli na front end oraz back office. Systemy front end, s to aplikacje przeznaczone dla klientów banków, biorcych udział w procesach trade finance. Głównym zadaniem tych systemów jest umoliwienie klientom dost-pu do zawartych przez nich transakcji oraz, w miar moliwoci, składanie rónego rodzaju wniosków. Specyfika tego zagadnienia sprawia, i systemy front end nie mog stanowi jedynie platformy informacyjnej, pozwalajcej na proste składanie zlece. Operacje trade finance s zagadnieniami trudnymi, wymagajcymi czsto duego dowiadczenia w handlu midzynarodo-wym i znajomoci przepisów midzynarodowego regulujcych ten handel. Fakt ten midzynarodo-wymusza na
wytwórcach oprogramowania wspomagajcego trade finance, zaimplementowania narzdzi, pozwalajcych pracownikom banku na współtworzenie lub przynajmniej aktywne pomaganie w budowaniu wniosków TF.
Systemy te powinny by zaopatrzone w mechanizmy pozwalajce na wprowadzanie wnio-sków przez klientów i nastpnie ich udostpnianie pracownikom banku w celu dokonania oceny ich poprawnoci merytorycznej. Wanym aspektem jest to, aby wnioski na tym etapie obsługi nie były traktowane jako zlecenie klienta o zawarcie umowy a jedynie stanowiły form projektu wniosku.
Systemy front end mog wspomaga dodatkowo komunikacj midzy klientem a pracowni-kiem banku, poprzez zastosowanie rónego rodzaju komunikatorów, pozwalajcych na przesyłanie zapyta ze strony klienta czy uwag ze strony pracownika banku.
Inna wan cech systemów front end jest moliwo wykorzystania wczeniej wykonanej pracy do budowy nowych wniosków. W tym celu stosuje dwie proste techniki:
• Moliwo wykorzystania istniejcych wniosków lub umów. Na ich podstawie tworzony jest nowy wniosek z warunkami wniosku lub umowy ju istniejcej w systemie.
• Moliwo budowania i wykorzystania szablonów wniosków. Szablony tworzone s z re-guły przez uytkownika, na podstawie zebranych dowiadcze lub na podstawie istniej-cych, dobrze sprawdzonych wniosków lub umów.
Inn rol warstwy klienckiej tych rozwiza jest umoliwienie klientom dostpu do przekro-jowych danych dotyczcych ich kontraktów w postaci rónego rodzaju raportów.
Systemy back office przeznaczone s dla pracowników banku, odpowiedzialnych za obsług transakcji TF. Zadaniem tych systemów jest obsługa procesów zwizanych z operacjami trade finance oraz dokonywanie wylicze niezbdnych wielkoci i ich rejestracja, zarówno w bazie danych transakcyjnych jak i w narzdziach ksigowych.
Rola tych systemów sprowadza si do rejestrowania i procesowania wniosków i spraw zwi-zanych z umowami. Systemy te czsto oparte s o rozwizania work flow, pozwalajce na proste budowanie przepływów wniosków i umów midzy odpowiednimi komórkami w banku oraz midzy innymi systemami.
Bardzo wanym aspektem funkcjonalnoci systemów back office jest komunikacja z innymi rozwizaniami, biorcymi udział w procesach TF. Dotyczy to głównie dwóch obszarów wymiany danych: wymiana komunikatów z innymi bankami oraz przesyłanie danych i odbieranie do/z in-nych systemów banku, najczciej systemu ksigowego (korowego).
Drugie kryterium pozwala na podział tych systemów na trzy grupy, w ramach kadej z nich na podgrupy:
• Systemy do obsługi akredytyw:
o Systemy do obsługi akredytyw importowych o Systemy do obsługi akredytyw eksportowych • Systemy do obsługi inkas:
o Systemy do obsługi inkas importowych o Systemy do obsługi inkas eksportowych • Systemy do obsługi gwarancji:
o Systemy do obsługi gwarancji udzielonych o Systemy do obsługi gwarancji otrzymanych
Automatyzacja procesów zwizanych z operacjami dokumentowymi.
Zarówno akredytywa dokumentowa jak i inkaso dokumentowe realizowane s w sposób od-mienny dla importerów i dla eksporterów. Std inkasa i akredytywy dzieli si importowe i ekspor-towe.
Systemy informatyczne musz posiada odmienne funkcjonalnoci, pozwalajca na obsług inkas i akredytyw na rzecz importera i eksportera.
Akredytywa importowa
System informatyczny powinien wspomaga obsług akredytyw importowych w zakresie po-niszych operacji:
• Obsługa wniosków o akredytyw importow, w tym obsługa draftów wniosków • Rejestracja umowy (sprawy) akredytyw importowej
• Uzgadnianie/odrzucenie dokumentów otrzymanych z banku eksportera • Realizacja akredytywy – wypłata rodków z tytułu akredytywy Akredytywa eksportowa
Obsługa akredytyw od strony eksportera jest troch bardziej skomplikowana ni od strony importera. Eksporter ma moliwo składania dodatkowych wniosków dotyczcych akredytywy:
• Wniosek o przeniesienie akredytywy • Wniosek o cesj
• Wniosek o przeniesienie wpływów • Wniosek o dyskonto akredytywy • Wniosek o potwierdzenie akredytywy
Do złoenia kadego z wniosków, systemy informatyczne powinny by zaopatrzone w obsług odpowiednich formularzy w portalu klienta oraz ich procesowanie w czci back office systemu. Niektóre z wniosków, jak: wniosek o dyskonto akredytywy czy wniosek o jej potwier-dzenie, wymagaj zgody departamentu kredytowego. System back office powinien by zaopatrzo-ny o rozwizanie work flow, pozwalajce na modelowanie procesu.
Typowe czynnoci zwizane z zarejestrowaniem i obsług akredytywy eksportowej polegaj na moliwoci odbierania komunikatów Swift o otwarciu akredytywy importowej w banku impor-tera i/lub komunikatów Swift o zmianie warunków akredytywy. System informatyczny w banku eksportera powinien pozwala na odebranie odpowiednich komunikatów oraz wykonanie automa-tycznie czynnoci zwizanych z ich dalsz obsług: załoenie akredytywy eksportowej i powiado-mienie o tym fakcie klienta czy te automatyczne dokonanie zmiany jej parametrów. Koncepcja automatycznego reagowania na nadchodzce komunikaty oraz automatycznego ich wysyłania na podstawie czynnoci wykonywanych w systemie nazywa si Straight Through Processing (STP) i jest jednym z podstawowych załoe systemu Swift.
Inkasa dokumentowe
Obsługa inkas dokumentowych jest generalnie znacznie prostsza ni obsługa akredytyw. W zalenoci od strony transakcji, systemy informatyczne musz zapewni automatyzacj co najmniej czynnoci:
• Inkaso eksportowe:
o Obsługa wniosku o inkaso dokumentowe
o Prezentowanie i negocjowanie dokumentów handlowych o Obsługa płatnoci zwizanych z inkasem
• Inkaso importowe:
o Rejestracja inkasa na podstawie otrzymanego wniosku o Prezentacja dokumentów
o Obsługa płatnoci z tytułu inkasa.
W wikszoci czynnoci te obsługiwane s w sposób analogiczny do akredytyw, z t podsta-wow rónic, e inkasa nie wymagaj dokonywania ksigowa pozabilansowych.
Gwarancje bankowe
Funkcjonalno systemów informatycznych, zwizana z obsług gwarancji bankowych uza-leniona jest, tak jak w przypadku operacji dokumentowych, od strony transakcji handlowej czy usługowej. Wnioskodawc gwarancji jest strona zamawiajca towar lub usług, za jej beneficjen-tem dostawca. Std te gwarancja od strony wnioskodawcy nazywa si gwarancj wystawion, za od strony beneficjenta gwarancj otrzyman.
Gwarancje wystawione
Podstawow obsług oferowan przez systemy informatyczne jest moliwo obsługi wnio-sków o wystawienie gwarancji oraz realizacja gwarancji.
Informacja o wystawieniu gwarancji wysyłana jest do banku beneficjenta za pomoc komuni-katu Swift MT760, z tego te powodu formularz wniosku powinien posiada szereg walidacji, pozwalajcych na takie przygotowanie wniosku przez klienta, aby spełniał on podstawowe wymo-gi techniczne systemu do obsłuwymo-gi komunikatów Swift.
Podobnie jak w przypadku akredytyw importowych, obsługa wniosków o gwarancje bankowe moe zosta podzielona na obsług draftów wniosków oraz na obsług właciwych wniosków.
Otwarcie gwarancji bankowe wie si z koniecznoci zarejestrowania szeregu zabezpiecze tej gwarancji, przeprowadzeniem procesu weryfikacyjnego, w tym weryfikacji kredytowej oraz dokonaniem zapisów ksigowych.
Realizacja gwarancji jest czynnoci polegajc na dokonaniu płatnoci z tytułu gwarancji. Gwa-rancja zrealizowana moe zosta na wyrane danie beneficjenta gwarancji.
Zrealizowanie gwarancji wie si z postawieniem gwarancji w stan natychmiastowej wyma-galnoci. Std systemu informatyczne powinny by zaopatrzone w narzdzia pozwalajce na naliczanie odsetek karnych oraz obsług windykacji zarówno mikkiej jak i twardej.
Gwarancja, do które nie wystpiono z daniem realizacji automatycznie wymaga. System in-formatyczny powinien pozwala na automatyczne zamykanie gwarancji w chwili gdy mija jej termin wanoci. Zamknicie gwarancji dokonywane jest w procesach koczcych dzie roboczy i wie si z wyksigowaniem zobowizania gwarancyjnego, zwolnieniem zabezpiecze oraz zamkniciem rachunku gwarancji.
Gwarancja otrzymana
Obsługa gwarancji otrzymanej jest znacznie prostsza od gwarancji udzielonej i ograniczana do jej zarejestrowania oraz zamknicia albo na podstawie płatnoci wynikajcej z realizacji gwa-rancji albo w wyniku minicia terminu jej wanoci.
4. Komunikaty Swift w Trade Finance
Jednym z podstawowych narzdzi informatycznych stosowanych w trade finance jest nikacja za pomoc rozwiza Swift. Poniej zamieszczona jest lista najczciej uywanych komu-nikatów, odpowiedzialnych za przekazywanie rónych zdarze wizanych z obsług instrumentów trade finance:
Akredytywy i gwarancje:
MT700/MT701 – otwarcie akredytywy MT705 – awizo akredytywy
MT707 – wniosek o zmian warunków akredytywy MT710 – awizo do banku poredniczcego
MT720 – transfer akredytywy do innego banku MT730 – potwierdzenie odbioru akredytywy
MT732 – awizacja potwierdzenia (akceptacji) dokumentów MT734 – awizacja odrzucenia dokumentów
MT740 – autoryzacja rembursu (pokrycia) MT742 – danie rembursu
MT750 – awizacja niezgodnoci MT752 – autoryzacja płatnoci MT754 – awizacja płatnoci MT760 – awizacja gwarancji
MT767 – zmiana warunków gwarancji Inkasa dokumentowe
MT400 – awizacja płatnoci z tytułu inkasa MT405 – inkaso bezdokumentowe
MT416 – awizacja braku płatnoci/akceptacji MT430 – zmiana warunków inkasa
5. Podsumowanie
Usługi z zakresu finansowania handlu jest jednymi z wielu oferowanych przez banki klientom instytucjonalnym. Specyfika tego produktu polega na pełnieniu przez banki roli doradcy z zawieraniu tych transakcji ze wzgldu na duy stopie skomplikowania operacji zwizanych z handlem midzynarodowym. Realizacja tych usług bez zastosowania systemów informatycznych jest prawie niemoliwa a na pewno bardzo utrudniona. Wpływ na taki stan rzeczy ma kilka aspek-tów:
Konieczno stosowania jednolitej komunikacji w wymianie informacji midzy bankami, uczestnikami transakcji trade finance – najczciej stosowanym standardem wymiany danych s komunikaty Swift, co wymusza konieczno dostosowania si formatem danych oraz składni danych do standardu narzuconego przez t organizacj
Powszechna dostpno Internetu w szczególnoci w kontaktach klientów z bankami a take skomplikowanie procedur handlu midzynarodowego, wymuszaj na bankach udostpnianie klientom portali internetowych, w których klienci nie tylko mog składa wnioski czy przeglda obsługiwane sprawy, ale take konsultowa z dowiadczonymi pracownikami banku form oraz posta składanych wniosków.
Trade Finance jest jednym z produktów bankowych i czynnoci z tym zwizane wymuszaj na bankach dokonywanie odpowiednich rejestracji ksigowych. Przepisy ksigowe narzucaj konieczno jednolitego ksigowania w specjalnych rejestrach zwanych ksigami głównymi banku, zgodnie z zasadami rachunkowoci polskiej i midzynarodowej. Niewyobraalnym jest dokonywanie rejestracji zapisów ksigowych bez udziału systemów informatycznych. Wymusza to zastosowanie Informatyki do realizacji czynnoci zaliczeniowych i ksigowych do operacji Trade Finance.
W kontekcie przytoczonych aspektów, szczegółowo opisanych we wczeniejszej czci arty-kułu, wydaje si zasadnym postawienie tezy, e oferowanie przez banki usług zwizanych ze wspomaganiem handlu midzynarodowego nie moe si obej bez stosowania narzdzi informa-tycznych. Za standardy, narzucane przez organizacj Swift, na pierwszy plan wysuwaj zastoso-wanie narzdzi elektronicznej wymiany danych.
Bibliografia
[1] A. Gospodarowicz (red.), “Technologie informatyczne w bankowoci”, Wydawnictwo Akademii Ekonomicznej we Wrocławiu, 2002.
[2] A. Pawełczak, „Informatyka bankowa”, Wydawnictwo WSB, Pozna, 1998.
[3] Z. Ryznar, „Informatyka bankowa. Próba syntezy”, Wydawnictwo WSB, Pozna, 1998.
USING THE EDI IN TRADDE FINANCE PROCESSES Summary
The aim of this article is showing of necessity of using IT solutions for require-ment of bank activities in fields of trade finance operations. Author describes the main base of trade finance and the role of IT solution in realization of activities refer to trade finance. The article focuses on the role of EDI as a main solution in inter-changing information between banks of importer and exporter and between banks and their clients.
Keywords: Trade Finance, EDI, Letter of Credit, Guaranties, Documentary Collections, Swift
Jarosław Zajc
Katedra Informatyki Ekonomicznej Wydział Ekonomiczno-Socjologiczny Uniwersytet Łódzki
ul. Narutowicza 65, Łód e-mail: jzajac@uni.lodz.pl