Minden hazai bank felkészült az azonnali átutalási rendszer startjára - hangzott el a Magyar Bankszövetség évindító sajtóbeszélgetésén. A rendszer március másodikán startol, mindenki számára elérhető lesz, akinek hazai számlacsomagja van.
[...]
A GIRO egy új rendszert épített ki, az MNB szabályozza, felügyeli és összefogja a projektet, a bankszektor pedig 30-40 milliárd forintért fejlesztett, a kormányzat pedig támogatja a projektet.
2020. március másodikán indul el az új rendszer, amelyre valamennyi tag felkészült.
[...]
Az azonnali fizetési rendszerről az elnok elmondta, hogy több százezer munkaórát fordítanak a bankszektor munkatársai arra, hogy működjön a rendszer.
Ez a magyar bankrendszer valaha volt legnagyobb beruházása- jelentette ki Becsei András. Hozzátette, a fejlesztések kapcsán több bank is előrehozta a rendszerfejlesztéseit is, ami mindenképp mutatja a bankszektor elköteleződését az azonnali fizetési rendszer mellett.
Részletek itt.
Hozzászólások
Whoa!
Remélem a tranzakció SMS értesítésbe belefejlesztették azt a fícsört, hogy "ne zavarj" megadott intervallumban, pl. 18:00 - 07:00 között. (A telefonom nem tud feladó szerint differenciáltan jelezni.)
Pedig ez pont rossz lenne - hiszen ebben az időpontban, ha valaki kezdeményez az ellopott kártyaadataiddal egy vásárlást, nem kapsz róla értesítést, hogy hoppá, le kéne tiltani a kártyádat, mert gond van vele....kontraproduktív, ha egy 2FA-t be lehet úgy állítani, hogy "ne zavarjon".
Kártyakontroll SMS <> számlakontroll SMS
A kettőnek semmi köze egymáshoz.
az sms egyebekent is insecure es megbizhatatlan.
Miért lenne megbízhatatlan?
mert pl ut kozben az olvassa el aki nem akarja... es pl mindennnapos h kulfoldon tartozkodva nem ernek utol az sms-ek
Hát tudja a fene. Szerintem a legjobb a banki, parkolásos és ilyesmi esetekre. A legtöbb embert ezen keresztül lehet elérni. A külföld az viszont jogos.
Pici statisztika: az SMS-ek kézbesítési aránya 98% körüli, a mobil push notification-ok kézbesítési aránya 99.9% feletti volt egy (egyébként nem magyar, de ez nagyjából mindegy) banknál. Más kérdés, hogy az ügyfeleknek közel 100%-a kért SMS-est ott, és csak ~15%-a push notification-t.
Hát igen, ez szerintem elég jó arány. Főleg úgy, hogy a sikeresen kézbesített sms-ekről kapnak visszajelzést az alkalmazások, ha kérnek. Tehát, aki megkapta, arról tutira tudnak. Ez egy nagy előny, főleg ilyen nagy sikeres kézbesítési aránynál. Ráadásul nem kell hozzá se net, se semmi. A külföld az tényleg problémás lehet.
Azért térerő nem árt... emiatt nem raktam át a banki SMS-eket Digis kártyára...
Én rosszul vagyok az SMS-es ökörködésektől. Nézzük az alap felállást: az interneten csinálsz valamit, amihez második faktoros azonosításként SMS-t kérnek.
Gondoljuk csak ezt végig? Internet van, hiszen azon veszed igénybe a szolgáltatást. Mobilhálózat van? Az SMS-ek megjönnek? Teljesen feleslegesen hoz be egy olyan függőséget, amivel csak szophatsz.
Mondjuk az nem art, ha 2FA eseten a ket csatorna fuggetlen. :)
Például egy OTP megoldással (Google authenticator és tsai)? Egyébként ezt biztonsági szempontból sem feltétlenül tudom elfogadni. Ha az internetes titkosított csatornáidat kontrollálják, milyen jelentőséggel bír, hogy SMS üzenet után tudsz csak belépni?
Sokkal sűrűbben fordul elő, hogy az SMS nem (időben) érkezik meg, minthogy a TLS-t feltörjék.
jopar nap utan...
Az szép is lenne. Kb 1mp-en belül küldi az sms központ a kézbesítési jelentést. Inkább az a kérdés, hogy sikerül-e a kézbesítés pl. térerő probléma vagy egyéb miatt.
a kezbesiteettrol igen. a nem kezbesitettre meg van timeout h meddig probalja....
Igen, a retry policy szerint próbálja kézbesíteni egyre nagyobb időközönként, míg vagy lejár a kézbesítési idő vagy sikeres a kézbesítés.
Itthon melyik bank ad Push notification-t SMS helyett?
Tudtommal a Gránit ad.
:)
Engedélyezésre szerintem továbbra is SMS-t használ második faktornak a Gránit.
Értesítésre viszont a saját alkalmazását, ami legalább a legnagyobb SMS költségedet megszünteti.
Unicredit, K&H. Talán OTP.
"...handing C++ to the average programmer seems roughly comparable to handing a loaded .45 to a chimpanzee." -- Ted Ts'o
KH? Az nem csak SMS-t tud?
K&H tudtommal csak SMS. Nekem fenn van a mobilapp, de mindent SMS-ben küld.
Az OTP biztos nem, legalábbis én nem tudok róla.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
CIB is asszem tudja.
Biztosan tudja. Szoktam kapni aplikàción keresztűl értesítést
Magnet Banknál kódszó, login értesítés és kártyaforgalom is mehet PUSH üzenetben.
Nagy Péter
Magnetbank is add push notificationt
Mert példának okáért nem időgarantált szolgáltatás.Sőt, egyáltalán nem garantált szolgáltatás(!)
az.. hajnali 2kor jott az sms h kesik az elozo napi deelutan 2orai gepem
Nem időgarantált szolgáltatás. Ez tipikusan szilveszterkor látszik.
Szerintem egy push notif ami átmegy a fél interneten, utána meg ráugrik a toronyra, onnan meg te megkapod 4g -n, utána meg ... :) szintén nem garantált sehogy.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
Mégis a gyakorlati tapasztalatom az, hogy internetbanki (ami az elmúlt pár évben SMS authos volt) belépéskor az internetbankot elértem, de az SMS nem jött meg. Fordítva egyszer sem fordult elő!
Neekm az Ödönbank nem bír push-t küldeni...
Nálam az OTP-féle sms-ekkel nincs soha semmi problémám. Bár észrevettem hogy priorizálnak: kártya- és számlakontrollos sms rögtön megjön, ha terhelés, ha jóváírás, illetve a PSD2-es SMS-es is rögtön megérkezik, de van olyan tranzakció amiről utólag értesülök (pl. ha kártyás pénzküldéssel kapok pénzt, ha én küldök a terhelésről rögtön jön). De ez a különbség nem amiatt van, mert SMS-ről van szó, hanem amiatt hogy a kevésbé kritikus típusúakat tömbösítve adják fel.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
Sűrűn jársz amúgy külföldön? Nem ritka, hogy napos(!) késéssel jönnek meg az SMS-ek. Banki belépésnél ez erősen a kvaanyád kategória, nem gondolod?
Nekem úgy rémlik volt már 1 OTP-s második faktor sms ami órákat késett.
Meg a Paypal vagy Transferwise egyikéből is 1.
Hát persze, hogy nem, én nem tudok olyanról ami az lenne és ennyi ügyfelet lehet vele elérni. Ellenben mindenféle egyéb varázslás nélkül tudja a feladó, hogy a címzett megkapta az üzenetet. És a legprimitívebb készülékekkel is működik. Jelenleg még van létjogosultsága szertintem szolgáltatói szinten, főleg az árat figyelembe véve....
Btw épp most szabványosították az SMS-es OTP-t a webkit-ben: https://github.com/WebKit/explainers/tree/master/sms-one-time-code-form…
Nagyszerű, akkor most már rá fognak ugrani annak az ellopására is valahogy...
Ha androidot használsz, akkor az elég régóta tudja, kollegám szerint az ios is.
Ennek a világon semmi köze nincsa az azonnali fizetési rendszerhez...
Egy kis érdekesség: https://bian.org/wp-content/uploads/2019/09/BIAN-M4-Value-Chain-V8_0.pdf
Ezt a feltűnően rémisztő ábra tartalmazza azokat a területeket, amelyekkel egy bank általában foglalkozik. Viszonyításként az azonnali fizetések az Operations/Clearing and Settlement/Payment Execution dobozba tartozik, az értesítések meg a Channels/Cross Channel/Channel Activity History részbe. (Az egy teljesen más kérdés, hogy van olyan banki szoftver, ami speciel mindkettőt önállóan csinálja - dehát a banki architektúrákat általában nem a domain-ek szép elkülönítése alakítja, hanem a "melyik már meglévő szoftverbe/haverom szoftverébe lehetne legolcsóbban belerakni/úgy belerakni, hogy mindenki jól járjon a feature-t" vezérelv.)
Ez az ábra tetszik :)
Jó drágán kommentelték ki a delay, és sleep sorokat az utalások scriptjeiből.
Ha csak ennyi lett volna a megoldás, akkor már rég megcsinálják. Kicsit több mindent kellett faragni...
...úgyis jönnek...
Na ja... Az IG2 vs. IG3 nagyjából ég és föld... Pláne az elvárt válaszidőkkel, illetve korlátozott kapcsolatszámmal...
Oké, igaz, csak ezt az ügyfelek nem értik és nem is érdekli őket. És igazuk is van. Ők az eredményt veszik meg. Ergo az ilyen reakciók mellett szó nélkül el kell menni szerintem.
Ezen megfeküdtem. :-)
digitális kintszülött
:D
troll vagy vagy hülye?
Szerintem mindkettő (hülye troll) :-D
ez olyan mogorva kérdés, legalább egy smileyt rakhattál volna a kérdésed végére, ha már az enyém hiánya ennyire felzaklat téged.
Igazad van, péntek 16:30-tól hétfő reggel 07:00-ig nem lenne éppen hatékony sleep/delay-ozni... Mielőtt túlragoznánk: valahol van egy csodakapcsoló, ami azt jelzi, hogy munkaidő van-e, mert ha nem, akkor még az OTP egyik számlájáról sem megy át a pénz az OTP másik számlájára, hanem csak bekerül a 'feldolgozandók' fájlba.
Gyk: talán nem kellene UFO-energia ahhoz, hogy a mostani éjszakai/hétvégi működést lecseréljék a mostani nappali működésre. (De értem, hogy most nem ez történik, erre nehezebb lett volna 10000 emberév munkát ráírni.)
Gyk: ejszaka nem uresjarat van, hanem egy csomo stuff akkor fut ami nappal nem tud. Voltam olyan projektben (nem bank), ahol akkora volt a tranzakciok mennyisege, hogy 24 ora kezdett nem eleg lenni a 24 ora alatt osszegyult tranzakciok feldolgozasara (obviously sorban, mert olyan tema volt) es a napi allapot konzisztens backupjara.
Ezt megoldani baromira nem trivialis, mert hiaba pakolsz ala ~infinite hardvert, ha pl. nem parhuzamosithato a feldolgozas, es a queue-ba gyorsabban toltik a cuccot, mint ahogy ki tudod venni belole.
A feladat persze megoldhato, ugy nez ki, itt is sikerult, de messze nem olyan egyszeru, mint odabofogni egy forumra, hogy "csak ki kell venni a sleepet". lol
Nos, én három bankban éltem meg, hogy az éjjeli stuffoknak kezdett kevés lenni 12 óra....nem kis meló megoldani, hogy ennek ellenére az üzemi időben nyitva legyen az intézmény up to date adatokkal!
Az ilyen jellegű problémák akkor kezdenek igazán fájdalmasak lenni, amikor nincs 12 óra, mert csak a napi kereskedés zárása után kezdheted (mert akkor keletkezik az input adat), viszont amíg a feldolgozás el nem készül, addig a délutáni/esti műszak nem mehet haza.
De, ehhez _nagyon_ sok energia kell. Nem azért, mert nehéz megoldani, nulláról felépíteni egy, az azonnali fizetési rendszerhez kapcsolódó rendszert... ha nem is könnyű, de nem is nagyon nehéz. Azt mondanám, hogy ~100 embernap fejlesztés, és ugyanannyi tesztelés/hibajavítás. Ez egy közepes feladat, könnyen megugorható.
Na, akkor most ezt az új rendszert illeszd a bank meglévő 811 db egyéb rendszeréhez. Ez jelentősen megdobja a projekt költségeit és idejét, még akkor is, ha minden tökéletesen flottul megy, és minden korábbi rendszer az integrálhatóság magasiskoláját képviselni.
Valahogy így. És a rendszereken felül amelyekből van kismillió, ötven féle platformon 200 féle nyelven és logika mentén megvalósítva, ott van a jogszabályi háttér, ami mindent figyelembe vesz, csak azt nem, hogy manapság már nem kockás füzetben vezetünk számlát. És amikor ezekkel már kibékültél, úgy, ahogy megy a cucc, akkor jön, hogy versenyezz a konkurenciával. :) Jó kaland!
"mert ha nem, akkor még az OTP egyik számlájáról sem megy át a pénz az OTP másik számlájár"
Ez egész biztosan nem igaz. OTP számlák között éjjel nappal lehet utalni, mindegy, hogy a kedvezményezett számla a tiéd-e vagy Marika nénié Mucsajröcsögén. Emellett van egy külön funkció, ha tudod a kedvezményezett bankkártya számát, akkor kártya-kártya küldés is van, ami szinte azonnal teljesül, szintén éjjel nappal. Szoktunk egymásnak pénzt dobálgatni a nejemmel elég gyakran így.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
Hát, ennél azért bonyolultabb egy kicsit a dolog. Mondok egy példát, hogy milyen messzire vezető következményei vannak a bankok oldalán ennek az átalakításnak...
Tegyük fel, hogy a kedvesügyfélnek van egy hitele a banknál. A termék definíciója szerint a naptári hónapban kell megérkeznie a törlesztőrészletnek. Korábban ez azt jelentette, hogy a hónap utolsó napján az utolsó napközbeni IG2 csomagban kellett a pénznek megjönnie, ami még a csúszásokkal együtt is azt jelentette, hogy este 20:00 környékén megérkezett a bankba a pénz. A termék definíciója szerint a hónap fordulóján ki kell számolni az ügyfél tartozása kapcsán egy csomó mindent, pl. hogy mennyi a kamattartozása meg a tőketartozása - ami nyilván függ attól, hogy törlesztett-e az ügyfél az adott hónapban. Erre a banknak korábban 20:00-24:00 között volt 4 órája, halleluja, kiszámolták.
Az új rendszer segítségével az ügyfél akár 23:59:59.999-kor is törleszthet elvileg. Hát, eh...
A fentinél nyilván bonyolultabb a helyzet (olyan fogalmak kerülnek elő, mint könyvelési nap és hasonlók), de amiatt, hogy este és reggel között is működik a rendszer, sok banknak át kellett alakítania a saját belső működését, ami millió meg egy helyen épített arra, hogy éjjel nem interaktálnak az ügyféllel sehogysem. Mindezt átgondolva és kivitelezve bankonként párszáz-párezer termékre, lehetőleg úgy, hogy kevés panaszos ügyfél legyen.
Ebben a melóban sajnos elég sok tényleg bonyolult rész is van, meg egészen egyszerűen a mennyisége olyan, amit csak sok munkával lehet megoldani.
Vannak olyan folyamatok, amik az előző napi tranzakciókon mennek végig, és azt dolgozzák fel. Eddig ez mondjuk fixen hajanl 2-kor indult, és mondjuk 4-ig végzett is. Nem kellett szűrnie, mert hajnal 2-kor aznapi tranzakció még nem lehetett a rendszerben. Most, ha csak ennyi lett volna a fejlesztés, ez a script akkor is bedolgozná az aznap 0:00 és 1:59 közötti tranzakciókat is, ami már nem jó. Hamarabb pedig nem indíthatod, mert akkor még más folyamat fut.
Ilyenkor már egy delay kivétele is összedöntené a rendszert, ezért már ez sem lenne ilyen egyszerű.
(Én persze tudom, hogy itt nem ennyi volt, ez egy sokkal összetettebb átalakítás volt. Csak jó tisztába lenni vele, hogy ha egy delay lett volna, annak a kiszedése is hónapok munkája lett volna.)
Nagy Péter
CSAK KI KELLETT VOLNA VENNI A SLEEPET!!1 :Dszerk: eh, mar engem is faraszt a tema, pedig nagyon jol szorakoztam eleinte :(
SEPA utalásoknál már megvan ez a rendszer, de úgy tudom nem minden országban. De pl. Észtországban már van euró, meg azonnali euró átutalás is. Inkább euróra kellett volna már áttérni és csatlakozni a meglévő azonnali SEPA átutalási rendszerhez, mint fejleszteni egy teljesen újat. De ez is ilyen Hungarikum ezek szerint, hogy találjuk fel a spanyolviaszt sok pénzért. Bulgáriában, Romániában is előbb lesz euró, mint nálunk :(
A SEPA Instant CTS opcionális, csatlakoztunk mi is.
Az hogy van euró vagy nincs az teljesen mindegy a tranzakciók szempontjából, bitfolyam mindegyik.
Itt az MNB tette kötelezővé, ami szemben a SEPA Instant CTS-sel nem opcionális. A fejlesztéseket pedig a bankoknak kell elvégezni, amit a saját költségvetésükből gazdálkodnak ki.
Nem sírok miattuk, van ott pénz bőven.
...úgyis jönnek...
Hozzátenném, hogy (szerintem) a rendszer egyik elbaltázott része pont az, hogy tökre _hasonlít_ a SEPAInst-hez, de nem _azonos_ a SEPAInst-tel.
https://www.giro.hu/letoltes/hct-inst-szabalykonyv
35. oldal, Magyar sajátosságok, pl.:
"A HCT Inst üzenet text típusú mezőiben (ha azok nem azonosítók) az UTF-8 szerinti összes
alapkarakteren (a 32-126 közötti tartományban) kívül kizárólag a (128 fölötti „extended” ASCII
tartományban található) magyar ékezetes karakterek használhatók."
Sok sikert az Őrnagy utcában lakóknak a nagy Ő betűvel. Hogy ez mitől lett jobb, mintha meghagyták volna UTF-8-nak, nos, azt nem tudom.
Nem rossz... Ennyire fogalmatlanul az államigazgatásban szoktak megnyilatkozni... Hagyján, hogy az 'UTF8'-at 'Unicode' értelemben használja, de honnan tudjam, hogy mi nála az 'extended Ascii' -- 850, 852, cwi1, cwi2, iso8859-1, iso8859-2, 1250, 1252, egyéb? És ha ezt meg is mondja, akkor ténylegesen mi menjen az üzenetben: utf8 vagy a valamilyen singlebyte encoding?
Erre speciel egy másik dokumentumban van egzakt válasz, csak az a dokumentum nem publikus, csak a rendszer szereplői (bankok és hasonlók) számára elérhető.
Számomra érthetetlen, régen nyilvános volt a szabvány könyv, amiben ezek is megtalálhatóak.
Ez engem arra emlékeztet, amikor a névben lehet magyar ékezet, a jelszóban pedig nem lehet ékezet jellegű specifikációt úgy sikerült implementálni, hogy a névben csak magyar ékezet lehet, a jelszóban mindenféle ékezet lehet, csak magyar nem...
https://iotguru.cloud
Ennél sokkal nagyobb probléma is van ebben a mondatban. Az Ő betű az legalább magyar ékezetes betű, attól még hogy nem 32-126. De pl. egy umlautos a már nem magyar ékezetes betű, de attól még nevekben (nem csak magyar személy nyithat számlát) és valószínűleg címekben is megtalálható lehet.
Azert nincs euro, mert akkor az egybites is latna, hogy itt 500 a fizetes osztrakoknal 2000 nemeteknel meg 3000 ugyanazert a kuliert.
Nem mellekesen ha rontod a forintot, akkor a munkas nagyon olcso lesz, ez jo is, csak a rabszolga mar nincs roghozkotve svajci frank hitellel meg a sajat ostobasagaval ami a legnagyobb.
Vagy esetunkben fejlesztoi teruleten 2500 korul, meg a legrosszabb osztrak ajanlat ami beesett az 8400.
http://karikasostor.hu - Az autentikus zajforrás.
Hát ja, csak közben meg ha lenne euró, külföldi cégek is talán könnyebben jönnének.
Pl. Stripe még mindig nincs Magyarországon, viszont Észtországban már van. Gondolom azért, mert ott euró van.
Ez csak egy példa volt, de az tuti, hogy sok cégnek (mint most pl. a bankoknak ugye) túl sok felesleges kiadást jelent, hogy még mindig ez a gyenge kis forintunk van.
> Ez csak egy példa volt, de az tuti, hogy sok cégnek (mint most pl. a bankoknak ugye) túl sok felesleges kiadást jelent, hogy még mindig ez a gyenge kis forintunk van.
Nem nehéz összehozni, mivel 5000Ft-os SEPA átutalásra 2610Ft-os díj-at számol fel az OTP (0,35% min. 2 610 Ft/ max. 15 000 Ft).
Ez különösen kellemetlen volt, amikor külföldi payment processor hetente automatikusan utalta a kifizetett összegeket. A megoldás egy külföldi bankszámla nyitás, majd onnan TW-al hazajuttatni az összeget, de macera + további költségek.
Szerencsére az EU ezt is megregulázta, januártól nem kérhetnek többet érte mint a forint utalások költsége: https://www.otpbank.hu/static/portal/sw/file/LAK_Bankszamlak_H_20191220.pdf
majd hozzadragul a forint IS
Van az az elmélet, amely szerint a 350+ os euró is feltétele volt, hogy a BMW debrecenben telepedjen meg :) Ezt euróval ugye nem lehetett megtenni.
Miért jó a 350-es euró a bmw-nek? Mert ő euróban számolja a fizetést.
Ha a magyar belekerül neki (adókkal) 300 000 Ft-ba. Az 300-as eurónál 1000, 350-esnél meg 857 euró. 15%. Induláskor 1000, később 2500 fő kulis lesz ott rabszolgáztatva.
Éves szinten ez bizony 1,7 millió euró.. hát, ezt még át kell számolni, mert egy BMW-nek ez kerekítési hiba.
Nem tudom a 8400-at honnan kaptad, de az valami nagyon speciális terület lehet. Bruttó 5000-től már elég jónak számít Ausztriában egy seniornak is.
Hozzaszokhattal volna, hogy a HUP-on mindenki agysebeszi szinten muveli a szakmajat lett legyen az barmi amivel nincs semmi baj ha nem azt tekintjuk minimum osszegnek.
Hát az IG2 és IG3 speciel pont a SEPA sturtúráit használja. Mind a kötelező és nem kötelező összes mezővel... Nincs új a nap alatt..
Sic itur ad astra!
40 milliárd / 100 000 munkaóra = 400ezer / óra nem rossz...
A Bitcoin 8000 programsorból megvolt, bár ez biztos sokkal bonyolultabb rendszer, de azért a többszázezer munkaórát kicsit túlzásnak érzem.
A 30-40 milliárd csak becslés lehet, mivel a bankok nem fogják megmondani a teljes költségét az MNB-nek, mivel nem kötelező.
A fenti összegbe pedig beletartozik minden (infrastruktúra csere/frissítés; új megoldások, szolgáltatások bevezetése/vásárlása; konzultáció; oktatás, stb...).
A munkaórát meg ne egy emberre osszuk el, hanem sok-sok emberre. Így kicsit másképp jön ki a matek.
Ha 400ezer / óráért eladnának a kereskedő kollegák, akkor fényesre lenne nyalva mindenük, nemtől függetlenül. :)
...úgyis jönnek...
Na ja... És nem csak fejlesztés volt/van/lesz (még a hátralévő időben), hanem folyamatos tesztek mennek, amik irdatlan mennyiségű emberi erőforrást képesek elvinni.
Ha jól tudom az IG3-nál ugyan úgy mint az IG2-nél volt a bankok párba vannak állitva teszteléshez, plussz minden párhoz a GIRO ZRT. is. Azért három intézmény egyidőben tesztelését nem egyszerű összehozni csak tesztelői oldalról sem.
Sic itur ad astra!
Ezt ebben a formában nem tudod jól, de majdnem.
Sokféle teszt van, és a jellemző, hogy a bankok csoportokba vannak szervezve, és egymással tesztelhetnek, úgy, ahogy megbeszélik + vannak kötelező formamutatványok, amiket be kell mutatni, pl. a napi átlagos tranzakcióforgalom felét át kell tolni adott napon a rendszeren meg hasonlók. A részletek (csoportok, pontos követelmények stb.) a szereplőkön kívül mások számára azt hiszem nem publikusak (pedig nagy titok nincs bennük).
100k munkaorabol mi jon ki? Az kb 60 ember-ev.
Vargane es Tsa. BT-ben ez soknak tunik, de egy nagy organizacioban ez semmi.
És nem egy szervezet. Hány bank van Magyarországon?
Innen érdemes tájékozódni:
https://www.mnb.hu/letoltes/sht.xlsx
Nagyjából 44 (az egyedi BIC kódokat kell megszámolni), de nem mind csatlakozik az azonnali fizetési rendszerhez, illetve lehetnek olyan nem-bankok, akik szintén kapcsolódnak majd.
egyuttal varhato a dijak emelese is mert igy is tul olcso a magyar bankolas.
http://karikasostor.hu - Az autentikus zajforrás.
Hát attól függ, hogy mennyire nem olvastad el a lehetőségeidet. Nekem ingyenes bankszámlám van, ingyenes dombornyomott kártyával, ingyen netbankkal. Elég egyszerű feltétele van ennek, oda kell érkeznie a fizetésemnek, és használni a kártyát. Ami nem abból áll, hogy fizetésnapon leballagok és kp-ra konvertálom az egészet, hanem teljesen kp. mentesen élek, mindenhol csak kártya. Emiatt van egy extrám is, a bankszámlámon lévő pénz IS kamatozik, nem csak az amúgy bármilyen számlavezetés nélkül igénybe vett megtakarítási számla.
Aktív bankkártya mellett van egy digitális kártyám, ami évi pár száz ft.
Van egy hitelkártya, ami bárhol használható azonnal 0THM-es áruhitelre, ennek havi díja van, ami magát a számlát, a kártyát, a netbankot, és egy fedezeti biztosítást tartalmaz, hogy ha ellopják és felhasználják a kártyát, akkor a teljes összeget, amit elloptak, bizony visszaadja a biztosító.
openSUSE Leap 15
Mennyit is? A bank nem jotekonysagi intezmeny - ha 0.15% "premium" kamatra ott tartod a penzed, akkor az ingyen szamlavezetes nem akkora deal.
Ez egy extra. Még az az évi pár száz HUF is bőven jobb, mint ha nekem kéne fizetni. Attól meg főleg jobb, hogy amíg használtam kápét, évi 15-20%-ot buktam vele, mert az aprót elszórtam menet közben.
openSUSE Leap 15
Ez a marketing. Lehet, hogy ahol 500 forinttal dragabb a szamlavezetes, ott a befektetesed meg 600 forinttal tobbet hoz. Onamagaban az, hogy ingyen van a szamla meg az SMS, az csak marketing.
Mi?
:)
Amikor utoljara bankot valtottam, dragabb lett a szamlavezetes X forinttal, viszont Y>X forinttal csokkent az ertekpapir szamlavezetes es -tranzakciok koltsege, es Z>>>>>X forinttal csokkent a lakashitel torleszto. Nem olyan bonyolult ez. Mire vagy pontosan kivancsi?
Miért nevezed marketingnek, amit a másik tapasztal? Nem állította, hogy nem létezhet a szokásaihoz jobban passzoló szolgáltatás, csak azt mondta, a mostani megfelel neki.
:)
Ha azt mondta volna, hogy X forintrol Y forintra csokkent az osszes banki koltseg, azt elhiszem, es egy pillanatig nem firtattam volna a kerdest. Ha azt mondta volna, hogy neki A bank szimpatikusabb mint B bank, azt megertem, az ember nem robot, ez is lehet egy szempont.
Viszont. Azert nevezem marketingnek, mert olyanokat irt, hogy "Amíg nem akar lehúzni, mint egyes más bankocska, addig nem sajnálom tőle azt a pár %-ot". Ebbol ket dologra tudok kovetkeztetni (es fixme, ha tevednek):
A bank egy for-profit intezmeny. Nincs olyan, hogy ingyen van.
Jaja, mindent megértesz, csak azt nem, hogy jó így neki. Találgatás helyett legalább megkérdezhetnéd, hogy mi van, és akkor talán elmondaná, hogy miért elégedett. De nem, te mint valami cápává változott ügynök próbálod a farkaddal beleverni a fejébe, hogy szar neki.
:)
Az elso hozzaszolasom a threadben egy konkret kerdes volt, akkor fordult filozofiai vitaba a dolog, amikor nem jott ra valasz.
Kb.: – Vásárol egy új kalapot? Az én kalapjaim nem csúfítják el úgy.
:)
Egy konkret, szamszeru ertekre kerdeztem ra. Nem olyan bonyolult ez.
Sosem dolgoztam olyan banknal, ami Magyarorszagon vegez penzugyi tevekenyseget, ugyhogy oszinten nem erdekel, ki hol tartja a penzet. Az ideologia viszont erdekel mogotte, mert amig az atlagember 5% kulonbsegert az arukereson mar egybol kattint az eloreutalos kamu webshopra (itt a hupon is szoktak neha sirni, hogy beszoptak), addig penzugyi teruleten ugy dobaloznak 5%-okkal, hogy orom nezni.
Talán célravezetőbb lenne, ha a kérdésfeltevés után nem éreztetnéd a kérdezettel, hogy esélyesnek látod, hogy ő egy szerencsétlen hülye.
:)
Nem kell mindenen megsertodni. ¯\_(ツ)_/¯
Plane nem, ha valaki azt teszi szova, hogy a bank nem azert csinal valamit, mert jofej, es szeret teged.
Tisztelem, hogy nem elégedsz meg azzal, hogy nyomorultnak néznek, még teszel is rá egy lapáttal.
:)
:’(
Bár a korábbi hozzászóló csomagját nem ismerem, de nekem nincs sem számlavezetési díjam, se az utalásnak díja 100.000 huf/tétel alatt (bármennyiszer egy hónapban). 30 tételben akár 3 millió forintot is el tudok utalni belföldön bárhová ingyenesen. A készpénzfelvétel Havi 150 ezer forinting nyilatkozat nélkül is ingyenes, mint ahogyan a készpénz befizetés is.
Továbbá:
A Dombornyomott MasterCard bankkártya 315 Ft.
Ja, és Forgalmi kivonat postai kiküldéssel: 0 Ft/kivonat (de nem kérem, jó nekem a netbankban)
Mindemellett kb 5 éve egy hitel miatt kellett hiteles igazolást kérnem a számlatörténetemről. Bementem, elmondtam, hogy mit szeretnék. Nyomtattak vagy 40 oldalt, lepecsételték, aláírták mind. Azért sem kellett egy forintot sem fizetnem.
Szóval az nem igaz, hogy biztosan mindenkinek csak ügyes marketingesei vannak, és közben meg lehúzzák az embert. Lehet olyan számlacsomagja valakinek, ami megéri neki, és mondható rá joggal, hogy ingyenes.
Nagy Péter
Mi lesz a következő? Bizonygatnunk kell, miért azzal házasodtunk össze, akivel? :)
:)
Nos...igen! Mikor, hol, kivel és miért? Elő a farbával, elég a titkokból!
És gendersemlegesen a jó édes felmenőjét annak a gyalázatos embernek, aki nem sorolja fel részletekbe menően, kit és miért nem vett el! A progresszív modern kor kívánalmai szerint a nem emberekről is be kell számolni!
:)
Helyes! A listázás úgyis divat. Így legalább gyönyörű képet lehet rajzolni mindenkiről, mindenkitől! :)
Nem véletlen szálltam ki a szálból.
openSUSE Leap 15
Most nem kezdenem el ujra a temat, a legelso kommentem arrol szolt, hogy nem csak a folyoszamla es annak koltsegei leteznek. Ha te semmit mast nem veszel igenybe a banknal, akkor persze valoban jo deal. Melyik bank melyik dijcsomagja ez?
Meta: Bele se merek gondolni, miről lehet szó a 'Folyószámlák összehasonlítása, költségek/kamatok' című topikban...
MagNet Bank, és az "Illetéktelen" fantázianevű számlacsomag.
Nagy Péter
több éve nem igényelhető
hogy is szoktak mondani a facebookra? "ha valami ingyen van akkor te magad vagy az aru"? :)
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Nem én, hanem a pénzem, amivel a bank keres. Amíg nem akar lehúzni, mint egyes más bankocska, addig nem sajnálom tőle azt a pár %-ot.
openSUSE Leap 15
Ja, csak nehogy kideruljon, hogy a par szazalek az mondjuk otszor annyi, mint amennyit a szamlavezetesen sporolsz. :D
Óh, egyszer érteném meg: miért kell nekem RAGASZKODNOM ahhoz, hogy amit meg lehet keresni az én pénzemmel, az feltétlenül az enyém legyen? Csücskösített példa: ha a család számára vásárolt zsírosbödönt nem töröljük ki kenyérrel, hanem kinyalja a kutya a felületén maradt zsírt, akkor pazarolok?
Lehet, hogy vannak emberek, akiknek fontos, hogy ne kelljen figyelni a költségek mértékét (mert nincsenek), ugyanakkor őt sem érdekli, mennyi LEHETNE MÉG a haszna.
Én momentán megértem a kedves hozzászólót (no offense).
Ha te dolgoztal meg azert a penzert, akkor ez nem olyan elvetemult elvaras. En is szoktam adakozni, altalaban havonta egy fix osszeget mindig mashova, de meg soha nem adakoztam banknak.
Annyi a különbség, hogy nekem semmit nem kell tennem érte, a banknál pedig jelentős mennyiségű munkát bele kell fektetni, hogy az én pénzemből haszon legyen, ami amúgy lehetővé teszi, hogy finanszírozzák a szolgáltatásokat, amiket én ingyen igénybe vehetek.
A Napi éppen olcsó bankolást jövendöl. Persze ehhez az is kell(ene) hogy a tranzakciós adót eltöröljék.
https://www.portfolio.hu/uzlet/20200129/totalis-keszpenzhaboru-es-szupe…
Meg az is, hogy a magyarok bankolása ne abból álljon, hogy amint megérkezik a fizu, kirántja egy ATM-ből KP-ben...mert onnantól ellenőrizhetetlen, hogy Béla számla nélkül olcsóbban dolgozik nekem. :D Az is igaz, hogy a kancsal unortodox óta nem nagyon érdemes megtakarítani, mert a megtakarítás rosszabb esetben több pénzbe kerül, mint amennyit hoz. De ez a kancsal előtt nem így volt. Csak akkor mindenki olvasás nélkül deviza hitelért rohangált, mer'olcsó. Szumma szummárum, a magyarok pü-i kultúrája van a béka segge alatt és ez az alapvető baj szerintem. Én egy átlagos kis faluban élek 2000 óta. Ha a helyi információs tőzsdén - kocsma - a beszélgetés erre fordul és kimondom a "lekötött betét", "rulirozó", "kamat", kamatos kamat", "sávos kamat" vagy arra vetemedek, hogy az "értékpapír" szót használom, akkor arra mindig az a reakció "Mer'a zsidók...", "Mér'a zsidóknak...", "Zsidók vezetik a világot.", "Egy zsidó felülről irányít mindent". Szóval ezt pü-i kultúrának hívni, hát lehet, csak akkor a pü-i kultúrára kéne egy új kifejezés.
Szerintem most sokkal jobban kényelmesebben meg lehet takarítani, mint 2010 előtt. -> ingyenes webkincstár számla -> inflációkövető állampapír vásárlás
Ha meg hosszabb távra akarsz félretenni nagyobb összeget etf vásárlás online....
Őszinte leszek. Én mostanában semmibe nem tennék pénzt, amiben az állam szó szerepel. Ki tudja mikor veszti el az én pénzem jellegét?
Ott van a magánnyugdíj. Az magán volt, aztán kiderült, hogy mégsem.
"- jelentette ki Becsei András. Hozzátette, a fejlesztések kapcsán több bank is előrehozta a rendszerfejlesztéseit is, ami mindenképp mutatja a bankszektor elköteleződését az azonnali fizetési rendszer mellett."
btw ezt csak én érzem úgy, hogy több bank itt == a hazai nagyobb bankok -> már réges rég fel vannak készülve erre (értsd, 0 érték 1-re állítása a konfigban kb) , de azért kellett valami szöveg ehhez hogy "eladható" legyen PRilag is ?
Vagy csak kicsit naív vagyok? :)
Szerintem kicsit igen, hazai nagybankrol nagyon kozelrol tudom, hogy nagyon feszitetten keszult el idore es egyaltalan nem volt meg mar regota.
Köszi az infót!
Miért, elkészült...? Szerintem mindenütt megy még most is a reszelés ezerrel, hogy a teszteken tudja mindenki hozni az elvárt szintet...
Van, ahol tudom, hogy elkeszult. ;)
Elkészült, vagy a teszteket (eddig) sikerült kipipálni? ;-)
Mondom, hogy elkeszult, konyorgom, bankban dolgozom, nem feltetelezem, hanem _tudom_. :D
Kész szoftver nincs, csak használatba vehető/használatba vett :-D Ezek szerint nálatok minden teszt "pipa", mindenki ölbe tett kézzel várja a márciusi indulást (na jó, a tesztekben azért ott kell legyetek ti is, ha jól tévedek)... ;-)
Ehh, ez innentol boven filozofiai kerdes, ugyhogy tekintsuk lezartnak a kerdest..
Tekintsük. Meg toljuk a teszteket, ahogy az a "metrendben" van :-P
Keresed a kakán a csomót rendesen. Elkészült. Én háromról is tudom. De nem ülnek ölbe tett kézzel, azt az egyszeri ember gondolja. Az elkészült itt azt jelenti - mint minden szoftvernél - hogy márciusban el fognak tudni indulni vele. A használata meg majd megmutatja, ki mire nem gondolt, ide értve az MNB-t, a törvényhozót, a GIRO-t és persze az adott bankot.
Na, akkor pattogjon a labda nálad. Egy példát mondjál kész szoftverre, ami az általad itt feszegetett módon készen van, soha többé egy bit nem változik benne, mer'kész van he! (Hajbazer mondaná, hogy a ZIKSZPÉ, de azt is csak abbahagyták.)
"Kész szoftver nincs, csak használatba vehető/használatba vett", mondtam korábban. És pont emiatt nem tudok olyat mondani, ami készen van :-P És a "márciusban el fognak tudni indulni vele" az pontosan annyit jelent, hogy "használatba vehető/használatba vett" (hiszen mennek az éles tesztek ugye...).
Hogy márciustól ki fog tudni elindulni, azt csak az égiek meg az MNB (de ebben nem vagyok biztos...) tudják :-D Most megyek vissza gályázni, mert ugyan elindulni el fogunk tudni mi is, de addig még van teendőnk, hogy jobban, üzembiztosabban, gördülékenyebben menjen az indulás és az afr éles üzeme. (Mert nem elindulni nehéz, hanem az sla-nak megfelelően működni/üzemel(tet)ni hosszabb távon).
Hogy az MNB, GIRO, meg a paragrafushuszárok mire gondoltak az egy (de lehet,hogy három vagy több) dolog, és vagy kiderül, vagy nem - a másik oldalon viszont tudom, hogy néhanapján mire gondolnak/gondolunk velük (és szűkebb környezetükkel) kapcsolatban :-D
Az időre alatt az eredeti tavaly júniusi határidőt érted, vagy a kitolt márciusit? Mert ha utóbbi, akkor az baromira nem készült el időre, mivel az idő tavaly volt.
Elég ránézni a webes jelenlétére ezeknek a bankoknak. 3 bankszámlám van, így csak ezekről tudok nyilatkozni:
- OTP: Ez a legnormálisabb, de gyakran van, hogy 30+mp-ig teker a mobil app, a max 1 hónapos visszanézhetőség a számlatörténetben egy vicc. Tegnap a mobil app órákig nem működött, a webes felület meg hibás jelszó hibát dobott (ma ugyanazokkal az adatokkal belépett)
- Raiffeisen: Elavult design, max 1 évig lehet visszanézni az utalásokat, sms-es küldözgetés mindenhol, próbáltak rámbeszélni értékpapír befektetést, de kiderült, hogy csak egy telefonszámot tárcsázva lehet a tranzakciókat intézni
- Gránit bank: Ugyancsak 10évvel ezelőtti design, mobil app megbízhatatlan, utalásokat új partnernek csak a web-es felületen keresztül lehet intézni
Az elmúlt 1 évben mindhárom banknál volt szerencsém személyes ügyéntézést igénybe venni: mindhárom helyről egy mappányi papírral távoztam 1 órás ügyéntézés után. (weben keresztül 5 perc alatt elintézhető lett volna, ha lett volna ilyen opció)
Én visszasírom az erste netbank régi, kőkorszaki felületét, mert ez az új netbank egy kalap szar. Most tekintsünk el a "modern", gyávaszkriptes megoldásoktól, mert nem elsősorban attól szar, hanem ahogy megcsinálták.
Pl. a kártyaforgalomnál a megjelenített dátum a tranzakció könyvelésének dátuma, ami helyett én nyilván azt szeretném látni, amikor az a kurva fizetés történt. Aztán a korábbi 15 perces timeout-ot levették 5 percre, ami önmagában is faszkorbácsdíjas mutatvány, de tudják fokozni! Egyrészt ez úgy 5 perc, hogy 3 perc után jön egy figyelmeztetés, hogy akarod-e folytatni amit csinálsz, és ha ezt választod, akkor sallangmentesen újratölti a felületet, minden addig bevitt adatnak annyi. (Ha nemet nyomsz, vagy letelik még 2 perc, akkor kivág, ez OK). Ja, és a rendelkezésedre álló - valójában - 3 percben hiába pötyögsz be dolgokat pl. az átutalásnál, az 5 perces visszaszámlálás simán megy mellette, csak akkor "nullázódik vissza" 5 percre, ha valami új lapot tölt be. Nem tudom, hogy szándékosan tudnék-e ekkora szemetet összehozni...
Detto minden fentebb leírt szóval egyetértek. Régen csodálkoztam h. másnak (pl. az istenveréses fosadék unicredit) milyen netbank nyűgjei vannak, mikor erste-nél villámgyorsan és egyszerűen ment minden hosszú éveken keresztül. Aztán 2018 októberében jól szétbaszták az egészet.
Kedvencem h. az időt a sajátgép órájáról veszi a GUI. Beállítom az időzáras kártyalimitet X óra Y perc. Letelt az idő a netbankon látszódó óra alapján, már mennie kell a fizetésnek, erre elutasítja. Vagy 2x rápróbáltam, de továbbra is reject. Ekkor nézem meg jobban a telefonom óráját: b+ még mindig van 2 perc a limit tényleges aktiválódásáig. Kiderült h. a gép órája vagy 7-8 perccel sietett. No comment, szerintem azóta is szar.
+1.
En emiatt otthagytam az erste-t a f*szba. Hasznalhatatlan szar lett.
Persze - gondolom - a bonusz megvolt a bevezetes utan a megfelelo embereknek.
Es amikor irtam nekik bugreportot, hogy az 5 perc az valojaban 3 es egy felkesz atutalas adatainak figyelmeztetes nelkuli kukazasa csak kellemetlen, de egy fogalmazas alatt allo reklamalo levelet kitorolni igazan nem szep dolog, akkor meg valaszoltak is, hogy "igen, a rendszer 3 perc utan alaphelyzetbe all, vagy kileptet."
/O\
Azota gondolom valakinel leeshetett a papirtantusz, mert nem reg feljebb vettek 3 percrol. Azt nem probaltam, hogy tovabbra is kirantja-e a szonyeget a labad alol.
Mennyi időtartomány az, amíg vissza akarod nézni a tranzakcióidat? Egyébként online addig tudod visszanézni, amíg a bank rendszere tárolja a live rendszerben. Az archív lekérdezés menüpontot keresed, de az nincs. Amikor te csak bankon belül utalsz, akkor is több számlamozgás van, mint egy terhelés és egy jóváírás. Az összes statisztika, technikai számla, ami az adott tranzakcióban érintett, kap terhelést és jóváírást.
Kicsit számoljunk: HUP Banknak van 400.000 magánszemély és 30.000 üzleti ügyfele.
Az üzletiek átlag napi két tranzakcióval bírnak, egy utalás, egy utalás fogadás.
A lakosságiak havonta egy utalás fogadás és öt utalást generálnak havonta.
Legyen ez egy egyszerű bank, ami csak forintban és csak utalni tud és egy tranzakció csak négy számlamozgással jár.
Üzleti ügyfelek tehát napi nyolc számlamozgást generálnak, ami 8*365=2920 számlamozgás/év/ügyfél. 30.000 ügyfél tehát évente 87.600.000 számlamozgást termel a tranzakciós file-ba.
Lakossági ügyfelek 24 számlamozgást generálnak havonta, tehát 24*12=288 számlamozgás/év/ügyfél. 400.000 ügyfél tehát évente 115.200.000 számlamozgást termel a tranzakciós file-ba.
A bank rendszerében tehát egy évben átlagosan 202.800.000 rekord van, amiből te a saját számláidhoz tartozókat lekérdezheted egy évre visszamenőleg. Ebből kiderül, kinek, mikor, honnan és mennyit utaltál, milyen közleménnyel, milyen tranzakciótípussal, illetve ugyanez az ellenkező irányból. Ez CSAK a tranzakciós file!
Ehhez hozzáadódnak normál bank esetében a kártya tranzakciók, konverziós ügyletek, betétek, hitelek amelyek sokkal bonyolultabbak a technikai számlamozgások tekintetében, azután a könyveléstechnikai számlák, amelyeken megjelennek napi, havi stb. összegzett forgalmak - vannak jelentési kötelezettségek is ugye - a deviza ügyletek - konverziós számlák, devizaszámlák és statisztikai számláik - értékpapír számlák, és még hosszan sorolható mi minden.
Minezt úgy kell tudni, hogy egy banknál a tv-i keretek között van előre és vissza dátumozott tranzakció is, így ez a file, érdekes struktúrákat tud produkálni. Arról a pár ezer járulékos file-ról nem beszélek, ami minden tranzakciónál megmozdul. Szóval ezen az adatmennyiségen kell minden nap rendszert zárni, úgy, hogy egy másolatán te éjfélkor is tudj a pizzádért fizetni online, de az reggel már a live rendszerben látszódjon. Riportok állnak elő a zárásban, ügyletek járnak le és könyvelődnek automatikusan, ügyfélértesítők készülnek, kivonatok és társai. A 24 órás ügyféligény miatt folyamatosan naprakészen rendelkezésre áll egy árnyék rendszer, hogy crash esetén egy eljárással erre átálljanak, mert ha ez a kis file, amit itt tranzakciós file-nak nevezünk, megsérül akár egy diszkhiba miatt, akármi más miatt, nos ennek a visszatöltése sem triviális önmagában, az indexeinek a felépítése órákig is tarthat, de belátható, hogy ebben az esetben a rendszer egy konzisztens állapotára van szükség, nem elég a sérült file helyreállítására - audit - hanem az egész adatbázist kell előkapni valahonnan. De te közben rendelhetsz pizzát, mert működni fog a bank.
Te mennyi időre adnál lekérdezési lehetőséget? Felelősséggel, 24 órás rendelkezésre állás biztosítása mellett és olyan, a pü-i élet terén "felkészült" ügyfelekkel, mint amilyen te is vagy. Az elmúlt harminc évben hány olyan esetről tudsz beszámolni, amikor egy bank úgy robbant le, hogy az ügyfelei csal kamillázni tudtak? Ebből hányat produkált az otp, a postabank és társai?
> Mennyi időtartomány az, amíg vissza akarod nézni a tranzakcióidat?
legalább jelenlegi + előző év (pl. adóbevalláshoz kellhet)
> A bank rendszerében tehát egy évben átlagosan 202.800.000 rekord van
Ez nem egy nagy szám, de ha az éles banki adatbázisban tárolás és keresés lassú, akkor a régebbi adatok lekérdezését egy külön rendszer is tudja biztosítani.
Ez nem nagy szám...de ez, ha elolvastál mindent, töredék szám. Olvassál lszi!
Hiába próbálod elhitetni, hogy megoldhatatlan probléma ekkora adat tárolása kereshető formátumban, de ezt pl. már a paypal 20 éve tudta bármelyik magyar banknál 100x több ügyféllel.
Csak teljesen más környezetben, teljesen más tranzakció számmal dolgoznak. De hát akinek az alma az körte...
Azért ne tegyünk úgy, mintha ez olyan irdatlan nagy adatbázis lenne, másrészt pedig a legtöbb ügyfélnek elég lenne, ha a havi kivonatok elérhetőek lennének a számlanyitástól kezdve, ami szintén nem egy olyan nagy feladat, ki kell toszni szalagra a bármilyen formátumba kiexportált havi kivonat adatait.
https://iotguru.cloud
Az ilyen "nem olyan nagy feladat"-okból van párszáz, olyanokis,amikre álmodban sem gondolsz. Az, hogy szerinted elég lenne minden üf.-nek a pdf kivonatot elrakni a bank részéről az érdekes felvetés, van nekije GDPR-es és egyéb vonzata is (ki férhet, ki fért hozzá, kinek a kivonatait lehet tárolni ésmeddig, hogyan mented, illetve archiválod, satöbbi), a workflow-ba belerakni, hogy rakja el a rendszer, a legkisebb probléma vagy feladat.
> ki férhet, ki fért hozzá,
Ugyanaz aki a tegnapi adatokhoz. Miért lenne ez más? (otp aszf szerint 5 évig visszakérhető bármi, még a telefonos felvétel is)
> kinek a kivonatait lehet tárolni ésmeddig, hogyan mented, illetve archiválod, satöbbi
Ezzel azt akarod mondani, hogy jelenleg nincs nincsenek tárolva az 1 évnél régebbi átutalások, mert túl bonyolult lenne?
Jo, de ha az ot evvel ezelotti kivonat kell, akkor rachetelsz az Ugyfelszolgalatos Alexara (nekem amugy mindig Alexandra van, ez veletlen, vagy hardcoded a nev? :D), es elkuldi neked viszonylag gyorsan. Szerintem ez boven jo, nekem nem feltetlen kell, hogy a netbankban dinamikusan lehessen query-zni ot evre visszamenoleg, ott eleg a PDF. Sot, altalaban ilyen idotavra mar nem a tranzakciok listaja kell, hanem a hivatalos kivonat NAV-hoz, stb.
Van bank amelyik meg tudja oldani.
Ha ez fontos feature, akkor ott kell bankolni, ha meg nem, akkor mindegy. Nekem egyszer kellett 1 evnel regebbi kivonat, ahhoz boven megfelelt a chat. Ha gyakran kellene, akkor ugy kell bankot valasztani, hogy ez menjen.
Általában az van, hogy úgyis meg kell oldani, ha nem te kéred el ügyfélként, akkor egy front office és/vagy back office ügyintéző fog szopni a dologgal, az meg több pénzbe kerül, mintha ügyfélként magad meg tudod oldani. Sőt, könnyen lehet azt mondani, hogy tessék letölteni az internet banki felületen, mert ott ingyen van.
https://iotguru.cloud
Én nem a kivonatról beszélek (az gondolom alap, hogy le tudjam tölteni visszamenőleg mindet), hanem konkrétan tranzakciót tudok keresni 5 évvel ezelőtt is (annél régebben azért nem, mert 5 éve nyitottam a számlát). Szóval, az felesleges picsogás, hogy nem LEHET megoldani. Maximum azt lehet mondani, hogy nem akarják megoldani, vagy nem kell.
Jó, de akkor jövőre már hat évre akarsz keresni és ha húsz év múlva nézed, akkor már negyed századra...ne akard. Vagy keress olyan bankot, aki ezt bevállalja. Az ügyfelek zöme megelégedik az egy évvel, régebbit pedig kikér e-mail vagy telefonos üf útján és kész.
Vagy elmegy más szolgáltatóhoz, akik ki tudják szolgálni ezt az "irreális" igényt.
A Transferwise esetén például nincs limit erre, pedig több mint 6 millió havi szinten aktív ügyfelük és több mint 4 milliárd GBP a forgalmuk, ismétlem, havonta. A Revolut esetén is simán egy suhintással visszamegyek három évet, mobilon, pedig nekik is 4 millió felett van a havi szinten aktív ügyfelük és nekik és 4 milliárd GBP felett van a forgalmuk, ismétlem, havonta.
Tudom, balfaszok, bezzeg a nagy múltú patinás bankok a talicskányi öltönyös pogácsazabálóval, azok aztán tudják, hogy ez lehetetlen dolog, meg se próbálkoznak ilyesmivel.
Nem tudom miért van az, hogy aki nagybankban dolgozik, rögtön úgy gondolja, hogy az a szakma csúcsa. Lófaszt.
https://iotguru.cloud
Tudtommal egyik sem kifejezetten bank...
A Revolut több mint egy éve bank. A Transferwise nem bank, hanem Electronic Money Institution, a két dolog között az alapvető működési szabályokat tekintve semmi különbség nincs, üzleti szabályokban van különbség, hogy például nincs lehetőségük betétgyűjtésre és nem hitelezhetnek, meg ilyesmi, de semmilyen egyéb szempontból nem működhetnek lazábban, mint a bankok.
A véleményed szerint amúgy mikortól lesz IT szempontból bank egy pénzintézet, amikortól nem fogják tudni kiszolgálni egy éven túl a számlatörténetet? Vagy mi nálad a vízválasztó? Szerintem most belementél egy olyan csőbe, amiből nem tudsz jól kijönni...
https://iotguru.cloud
" nincs lehetőségük betétgyűjtésre és nem hitelezhetnek, meg ilyesmi, " na ennek a szabályozási, IT és üzleti vonzatai nem terhelik őket... Bőven elég, hogy olcsóbban működjenek.
A bank nem IT-szempontból bank, hanem attól, hogy banki tevékenységre a felügyelettől engedélyt kap, és ennek birtokában a banki/bankszerű működéshez szükséges funkciókat, illetve azok jelentős részét megvalósítja. talán Zizi linkelte ezt a doksit - javaslom tanulmányozásra - ezt "csinája" egy bank...
És pusztán ettől képesek lesznek kiszolgálni évekre visszamenőleg a tranzakciótörténetet, míg egy bank nem? Szerintem ezt te se gondolod komolyan, holnap szégyellni fogod ezeket a mondatokat.
Képzeld, egy EMI is pont ilyen. A Revolut viszont bank, ott mi az érved? Amúgy a helyzet az, hogy még mindig az a téma, hogy mitől is annyira kurvára nehéz egy olyan tranzakciótörténetet implementálni, aminél évekre visszamenőleg meg lehet nézni online, azonnal, hogy mi történt és ezzel kapcsolatban teljesen irreleváns ez a mondatod, szóval ismét a bullshit megy...
https://iotguru.cloud
" És pusztán ettől képesek lesznek kiszolgálni évekre visszamenőleg a tranzakciótörténetet " - meglehet. Meg attól, hogy nem a magyar jogrendnek kell megfelelni - ezt se felejtsd el. És a revolut, ha megnézed alaposan, a banki funkcióknak csak egy elég szűk körét fedi le, úgy a szolgáltatásai,mint a működése tekintetében.
És mégegyszer, sokadszor: nem technológiailag kurvára nehéz implementálni, hanem az erre vonatkozó szabályoknak megfelelően implementálni és üzemeltetni nem egyszerű - és nem olcsó. És ha nincs rá tömeges igény valahol, akkor nem fognak beletolni egy rakat pénzt, hogy legyen. (Igen, egy rakat pénz kell hozzá, mert sem a vas, sem az üzemeltető nincs ingyen - nem, a tegyék ki egy teszklóspécére sata diszkekkel nem megoldás a vasra)
Aham, szóval szerinted egy-két nagyságrenddel több ügyféllel, havi tranzakcióval és forgalommal azért könnyebb megvalósítani évekre visszamenőleges online számlatörténetet, mert nem kell a magyar jogrendnek megfelelni vagy mert nincs például lakáshitel workflow? Áruld el már legyél oly kedves, mi az a különleges dolog a magyar jogrendben, ami miatt magyarországi bankok egy része erre képtelen? Vagy mi köze a hitelezésnek ahhoz, hogy mennyi tranzakciót lehet online megmutatni az ügyfélnek?
Szerintem aludj erre a dologra, mert egyre nagyobb faszságokat beszélsz és meg fogod bánni, ha visszaolvasod. Never go full retard...
https://iotguru.cloud
Te fejlesztő-only üzemmódban vagy, én meg nem. És a fejlesztők általában nemlátnak messzebb a kódjuknál. Egyébként nema zt mondtam, hogy azért, hanem lehet az is az egyik ok. A másikmeg az, hogy nem egy n+sok fejlesztő által összelapátolt bughal... akarom mondani (nem)integrált banki rendszerhez kellett hozzádrótozni egy funklciót, hanem alapból így lett kialakítva a számlavezető rendszer.
Egyébként meg az egy ilyen "szolgáltatás" elég cinkes is lehet - gondold végig: ha a szolgáltatáshoz tárolni kell a régi számlatörténetet, akkor az az adatkezelést - minden ügyfél tekintetében - jogszerűvé teszi. És senki nem ellenőrzi, hogy ezen histroikus adatokat a majdnembank csak az adott szolgáltatáshoz, vagy épp adatbányászatra is használja.
Szerintem nézd át a lineklt pdf-et, gondold végig, hogy az abban lévő elemekből mennyi szükséges, és mennyi "jó ha van" például a revolut működéséhez. Annak a revolut-nak a működéséhez, amely tetszőleges üf. beérkező utalását zárolhatja indoklás nélkül, és saját belátása alapján, vitatható adatkérések után "majd valamikor" oldja fel a zárolást.
Ja, olvass utána, milyen megőrzési időkkel működhet egy banki számlavezető rendszer - ez az egyik, a másik meg próbáld végiggondolni, hogy egy, az élessel azonos védelmet igénylő, egyre nagyobb adatmennyiséget kezelő archív rendszer menniybe kerülne, és mennyi hasznot hozna, majd hasonlítsd össze a két becsült értéket, és számold ki,hogy hányszorosa az egyik a másiknak, és hogy az így kijött időtávban megtérülő rendszert érdemes- e megcsinálni.
Ne erőltessed. Volt már egy projektje bankban és így rálát mindenre is.
Ha figyelmesen olvastál volna, akkor láthattad volna, hogy több projektem is volt bankban, de ezek közül egy olyan is volt, ahol az éves 202.800.000 rekordos - vastagon kiemelt - tranzakciószámodat nagyjából 15-20 perc alatt érte el a rendszer. És persze 7/24 üzemű volt.
Komolyan, tényleg ott tartunk, hogy a magyar banki szakma krémje szerint szinte a lehetetlennel határos küldetés online lekérdezni egy évnél korábbi számlatörténetet? Tényleg?!
https://iotguru.cloud
Hol lett leírva, hogy lehetetlen? Értő olvasás...? Az lett leírva, hogy picit összetettebb annál, hogy "írok egy-két select-et, a kimenetet meg odaadom egy pdf-generátornak, és kész". Úgy szoftverben, mint infrastruktúrában, illetve szabályozási dolgokban több/összetettebb. Ja, és van olyan is, hogy üzletileg megéri/nem éri meg.
Hol írtam, hogy lehetetlen? Azt írtam, hogy "a lehetetlennel határos küldetés". Értő olvasás...?
Hát, baszki, de, sarkítva nagyjából ennyiből áll és működik is ilyen rendszer. Tényleg nem értem, hogy mi ezen annyira összetett, lehoztam egy éves tranzakciótörténetemet, 50 kB nyers adat, hatfelé replikálva 300 kB egy évem története, tegyük fel, hogy átlagos ügyfél vagyok az éves 846 darab tranzakciómmal, 10 év 3 MB és 8460 darab tranzakció, 300 ezer ügyfél esetén ez 1 TB adatmennyiség, és 2,5 milliárd rekord, számlaszámra és time-range indexelve. Még egyszer mondom, 10 év adata. Mi a retkes lófasz van ott nálatok hozzáértő informatika helyett, hogy ezt az adatmennyiséget nem tudjátok se letárolni, se kiszolgálni? Mondom ismét: van olyan bank, ahol ez működik.
Tegnap óta folyamatosan azzal jöttök, hogy
- több százmillió rekord, világvége
- magyar jogszabályok és banki előírások
- GDPR és MNB
- nem szabad (!) a számlavezető rendszerben tartani (megőrzési idők)
- komplex, meg külön rendszer kell
- drága, nem éri meg
- nem bank, úgy könnyű
- bla-bla-bla, bullshit, nem gyűjtöm ki a faszságaitokat, amire ráadásul válaszolni se vagyok hajlandóak
Mindezt úgy, hogy több magyarországi bank is tudja, világszerte pedig még több, jóval nagyobb forgalmú pénzügyi cég is képes erre a bravúrra. Valószínűleg nincs zellerük, aki megmondaná nekik, hogy miért nem lehet megcsinálni, ezért egyszerűen csak végiggondolták és megcsinálták.
https://iotguru.cloud
"Hát, baszki, de, sarkítva nagyjából ennyiből áll és működik is ilyen rendszer. " - Vagy nem. Láttál már olyat, ahol számlavezető rendszert cseréltek? Mondjuk kétszer. És archív környezetből is van mondjuk 2-3, az aktuálistól teljesen eltérő DB-t használva. Na ott azért elég tornázós lenne egy-két selecttel összehozni a teljes számlatörténetet, pláne úgy, hogy az archív rendszerek hálózatilag elkülönítve működnek az élestől. Nos, ekkor is "csak egy-két select?" Mondjuk Progress az egyik, Firebird a másik, és mondjuk Oracle a harmadik adatbázisod... :-) Szóval...?
Láttam.
Ilyet is láttam. Sőt, olyat is, hogy az adattárház három különböző rendszer volt, évjárat alapján particionálva, mégis meg lehetett oldani a dátumvonalon túlnyúló report generálást.
A magyarországi bankok közül melyikben cseréltek az utóbbi 5 évben kétszer számlavezető rendszert? Aham, maximum egy bankban, de ott se történt két teljes csere. A többinek mi a mentsége arra, hogy nem tud 5 évre visszamenőleg online számlatörténetet adni? Befejeznéd végre ezt az ámokfutást, hogy miért nem lehet megcsinálni és egymás után hozni a balfasz példákat?
https://iotguru.cloud
Mások minősítése helyett válaszolnál arra a mellékes kérdésemre, hogy mi az a banki termék, ami egy bankban 15-20 perc alatt 200.000.000 rekordot termel? Dobd már le a kártyádat az asztalra vagy a nagy arcodat a sutba!
Ja, azt szimplán elírtam mobilról. Kétszer is említettem, hogy napi 16-20 millió rekordról volt szó, szóval értelemszerűen nem 15-20 perc, hanem 15-20 nap alatt termelt 200 millió rekordot, mert hétvégén jóval kisebb a tranzakciószám becsukott fiókok miatt. De szerintem erre te is rájöhettél volna, hogy elírás.
Szerintem meg te vegyél egy kicsit vissza az arcodból, próbáltál nagyot mondani magas lóról, hogy mennyire hihetetlenül problémás lenne a több évre visszamenőleges tranzakciótörténet, aztán nagyon nem jött be, mert egyrészt több magyarországi bank is képes erre a dologra, még több külföldi, ráadásul nem olyan nagy az adatmennyiség sem.
Nagyon sok dolgot el tudok fogadni azzal kapcsolatban, hogy miért nem lehet egy banknál több évre visszamenőleg tranzakciótörténetet online az ügyfelek felé kiszolgálni, de azt, hogy technikailag bonyolult vagy drága, illetve azt, hogy jogszabályok miatt nem lehet, azt kurvára nem. Aki IT ember pedig ezen okok mellett kardoskodik, azt bizony körberöhögöm és beteszem a "nagyarcú bankos balfasz" dobozkába.
https://iotguru.cloud
Na most menj a picsába! :D Aki akkora balfasz, hogy rá kell jönni mit is akart írni az hallgasson! :D Figyelj te királyfasz! Világosan leírták - jó, neked ez kihívás - hogy amire nincs egy bizonyos tömegű igény, azt nem fogják kiszolgálni, hogy ha te magadat kritikus tömegnek érzed, akkor is te vagy kénytelen elmenni oda, ahol megütöd az ingerküszöböt! Emellett kaptál némi rálátást valamire, amiről lila fingod nincsen, ez kiderült azért azoknak, akik belülről láttak már ilyesmit. No, semmilyen dobozkába nem férsz be! :D Akkora durung vagy, hogy cölöpöt lehet veled leverni!
Nézd, én eddig úgy tudtam, hogy tévedhet az ember, sőt, be is ismerheti, hogy tévedett, ráadásul itt egy mobilról írt elgépelésről van szó.
Bocsánat, de nem úgy kezdted, hogy ha nincs rá igény, akkor nem szolgálják ki, hanem elkezdted kiszámolni, hogy mekkora mennyiségű adatról van szó és próbáltál mindenki elborzasztani a százmilliós rekordszámmal, aztán pedig végig kiálltál amellett, hogy rettentő sok adatról lenne szó és kérdezgetted, hogy melyik bankok képesek ezt kiszolgálni. Amikor megírtuk, hogy melyik bankokról van szó, akkor azt szó nélkül hagytad többször is. Idézzelek vissza? Biztos erre van szükséged?
És persze kurvára nem válaszoltál a kényelmetlen kérdésekre, de ahhoz van arcod, hogy egy elgépelés miatt nekem támadj.
Nyilván így van, a büfébe jártam be évekig, nem pedig banki architektúrát érintő döntéseket előkészíteni és meghozni.
https://iotguru.cloud
Nem írta meg senki, melyik bankokról van szó. Várom a magyarországi bankok listáját! Idézzed már vissza lszi! Az is lehet, hogy átsiklottam felette.
Átsiklottál. Mi lenne, ha végigkövetnéd, hogy melyik hozzászólásodban kérdezted és megnéznéd, hogy jött-e rá válasz? Több ilyen is van.
Egyébként miért kell magyarországi bankra szűkíteni? Külföldön más mennyiségű adatot könnyebb kiszolgálni? Vagy hogy jön ez ahhoz, hogy mennyire sok több száz millió rekord évente?
https://iotguru.cloud
A magyar jogszabályi környezet miatt. Ezért érdekel. Nem találom, melyik az a magyarországi, aki évekre visszamenőleg onli8ne lekérdezést ad. Azt mindegyik tudja, hogy kérésre a kezdetekig visszamenőleg kiad ilyet.
Te most direkt csinálod, vagy trollkodsz vagy mivan? Több választ is kaptál rá...
https://hup.hu/comment/2438308#comment-2438308
Többet is írtunk már, többször, de mintha vakfoltod lenne rá.
Ne már, ismét a bullshit? Nincs konkrét ismereted a témában, de ezért beböfögsz valami hülyeséget, hátha ettől megáll az élet, vagy mi ennek az értelme?
Mondd már meg, melyik magyar jogszabály tiltja meg, hogy online és közel real time lekérdezhető legyen a számlatörténet évekre visszamenőleg? Nem érzed ilyenkor, hogy mekkora ökörségeket jelentesz ki?
https://iotguru.cloud
Egyedüli magyar nagybankként az otp van emlegetve, de ott ez érvényes:
nvm
Én csak felhoztam azokat a nehézségeket, amik szembejöhetnek, te viszont nagy arccal tartod azt, hogy egy-két select oszt' jó'van. Egyébként meg a "mi a mentség" kapcsán mondjuk az, hogy az erre vonatkozó ügyféligény nem indokolja a fejlesztést? Erre nem gondoltál? Meg arra sem, hogy folzamatosan jogszabálycsavargatások miatt kell a fejlesztőknek tornázni, n+1 jelentés után n+23-at is megoldani... Legutóbb pl. a PAD volt ilyen feladat...
Tényleg, látott már valaki kész, kiküldött PAD kivonatot? Ha igen, melyik banktól?
Hogyne, tudom, egy álló napon át folyamatosan hordtad be kintről a mindenféle válogatott faszságot, hogy miért nem lehet megcsinálni, aminek a fele szánalmas hülyeség volt (GDPR, MNB, jogszabályok, szabályok, számlavezető rendszer szabályai és a többi), egy része IT faszság volt, hogy mennyire sokba kerül meg mennyire nehéz üzemeltetni, a többi meg maximum kicsit növeli a komplexitást, de nincs olyan bank, ahol a 6-8 ilyen nehézséged közül kettőnél több egyszerre fennállna.
Minden más esetben is az abszolút worst case scenario az, amire a TCO-t tervezed? Vagy csak akkor, amikor így elgurul a gyógyszered?
Ügyféligény biztos van rá, tele vannak sírva a bankos fórumok, hogy lehessen. A kérdés az, hogy az üzlet mit akar. Ha akarja, meg lehet oldani. Ha nem akarja, akkor meg mindegy, hogy meg lehet-e oldani, nem lesz megoldva.
Inkább arra válaszolj, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer", ha már egyszer nekem szegezted ezt a kérdést...
https://iotguru.cloud
Én a helyedben elkezdeném megérteni, hogy problematikus is, de amire nincs akkora igény, hogy megérje a kiszolgálása, azt nem fogják kiszolgálni.
Egyébként érdekelne, hogy mi az a banki termék, ami olyan népszerű, hogy 15-20 perc alatt keletkeztet 200 millió tranzakciót egy bankban. Ez tényleg érdekelne...
Nem, én általában architect módban vagyok és egyformán balfasznak tartok mindenkit, aki csak a saját kis szemétdombján akar kiskakas lenni.
Igen, pont olyan balfaszok, mint az üzemeltetők, akik csak üzemeltetési szempontokat tudnak figyelembe venni.
Már megint kifogások és bullshit halmok, hogy miért nem lehet megoldani a feladatot.
Ismét leírom: ezek az adatok megvannak bármelyik bank esetén, mert meg kell lenniük. Írjam lassabban?
És bizony a bankok is használják adatbányászatra, erről szól szinte mindenhol az adattárház projekt, nyilván bányásznak benne, hogy az üzlet elé csinos kis grafikonokat és prezentációkat tudjanak tenni. Kérdezd már meg ott az adatbányászokat, legyél oly kedves, lehet, hogy sokat tanulnál a bank működéséről.
Megnéztem. Nem estem hanyatt. Kinőttem már abból a korból.
Világosíts fel, véleményed szerint milyen megőrzési időkkel működhet egy banki számlavezető rendszer? Bár ilyen konkrét kérdésekre eddig se válaszoltál, szerintem erre se fogsz. Feldobsz ilyen hülye kifogásokat, aztán nem reagálsz.
Ez az adatmennyiség jelenleg is minden bank esetén megvan, kezelni kell, satöbbi, mert nagyrészt törvényi kötelezettség, kisebb részt üzleti kötelezettség. Szerinted honnan vakarják elő az adatokat, ha bemegyek az OTP-be, hogy kellene a 2016-10-12 és 2016-12-15 közötti tranzakciótörténetem? Mondjuk a MagnetBank esetén pont balfaszok, de ott ez az időintervallum egy 301 ms ideig tartó lekérdezés...
https://iotguru.cloud
Nade, ha olyan baromi lehetetlen megoldani, akkor miért van olyan MAGYAR bank ahol meg tudják oldani?
Mert nincs nekik zellerük, azért.
Vannak bankok, ahol dugig vannak ilyen emberekkel, akikhez beülsz, mint szakértő és azt hallgatod egy-két-három órán át, hogy mit nem próbáltak még ki, mert úgyse működne; illetve sorolják, hogy az ezt megelőző meetingek során milyen indokokkal vetették el a felmerülő ötleteket. Tele vannak negatív és sértett emberekkel, akik minden változásba befeszülnek, minden plusz munkának keresztbe fekszenek, ja, és nem beszélnek egymással. Sok esetben annyi volt a munkám oroszlánrésze, hogy egy asztalhoz kellett ülniük olyanoknak, akik évek óta nem beszéltek egymással, de mivel ott voltam, mint külsős, moderálniuk kellett magukat és mind a kettőjük munkájára szükség volt.
Ilyen helyeken nem megy már keresztül az, hogy egy üzleti változás miatt több munka lesz és fel kell még venni embereket. Az ilyen helyeken az a mentalitás, hogy az embereket ki kell rúgni, nem még több léhűtőt felvenni. A változás akkor mehet keresztül, ha nem jár több munkával vagy költséggel, mint a megelőző állapot. Kivéve a törvényi kötelezettségek és a kényszerű munkák (upgrade, licenc váltás, arculat váltás, satöbbi), amivel manapság nagyjából 80 százalékban foglalkoznak a bankok. A maradék 20 százalék meg apró cseprő kis változtatások.
https://iotguru.cloud
"mit nem próbáltak még ki, mert úgyse működne" - vagy inkább azt szedik össze, hogy mi az, ami problémát okozhatna, illetve a teszteken problémát okozott - ugyanis így is lehet. A lehetséges problémák _és_ arra megoldási javaslat felvetése nem keresztbefekvés, bár a fejlesztők, meg a fejlesztőből lett "szagértők" mindazt, ami nem egyezik a saját elképzelésükkel, keresztbefekvésnek tekintik - tisztelet a kivételnek.
"ott voltam, mint külsős" - De sok ilyen "Pilatus a credo-ban" megszakértést láttam már...
"üzleti változás miatt több munka lesz és fel kell még venni embereket" - kifejezetten nem architect kérdés, onnan maximum az input jön, hogy adott erőforrásokkal vélhetően nem oldható meg, de ez is inkább a terület vezetőjének a kompetenciája eldönteni.
"a törvényi kötelezettségek és a kényszerű munkák [...] amivel manapság nagyjából 80 százalékban foglalkoznak a bankok" - na ezt talán a törvényalkotóknak meg a jogszabályokat sűrűn átértelmező/átalakító jogalkotóknak és jogalkalmazóknak kellene az orruk alá dörgölni. És itt visszakanyarodhatunk az elejéhez: ha egy szervezetet a jogszabályoknak csak egy része köt, akkor az rugalmasabban tud működni, mint az, amelyet egy rakat másik is terhel.
Ugyanannyi szabály köti, ne kezdjed már megint, hogy egy másik magyarországi bank más szabályok szerint működhet vagy egy másik európai bank más szabályok szerint működhet. Azért tud rugalmasabban működni, mert kibaszták már idejekorán azokat, akik a tipikus negatív hozzáállású emberek, akik az energiájuk nagy részét arra pazarolják, hogy olyan kifogásokat hozzanak mindennel kapcsolatban, mint amit te is műveltél a hozzászólásaidban.
Például, megválaszolnád, hogy "milyen megőrzési időkkel működhet egy banki számlavezető rendszer"?
https://iotguru.cloud
dup.
Te sem tudsz értően olvasni - nem az lettleírva, hogy lehetetlen, hanem az, hogy nem annyi, amennyit a kolléga beleképzel. Sem szoftver, sem infrastruktúra, sem szabályozás/szabálykövetés terén.
Kifogás, kifogás, kifogás...
Szakmai háttér?
Úgy van. Ha már nem tudsz érdemben hozzászólni, akkor vond kétségbe, hogy a másik fél ért-e a témához.
https://iotguru.cloud
Ehhez mit lehet érdemben hozzászólni? Idézem:
Írjam rá azt érdemben, hogy nyafogás, nyafogás, nyafogás?
Melyik banknál tudom online lekérdezni - még mindig ez volt a kiindulási pont - a számlatörténetemet 2000.01.01 és 2020.02.11 között? Érdekelne. Érted, leülök, lekérdezem és kitolom Excelbe mert csak. Ezt melyik csinálja meg?
Ja, úgy mindegyik, hogy írsz nekik és "elővakarják" hogy frankó idézettel válaszoljak. De itt arról volt szó a startvonalon, hogy a delikvens klikkel, hogy aszondja ide a tranzakciós listámat izibe és az jön ész nélkül azonnal évekre visszamenőleg. Na. Ezt melyik tudja? Nem kivonat, nem batchmajdegyszerjöneredmény, hanem klikk, jé itt van! módon.
Sopronbanknál tudok keresni tranzakciók között, vagy le tudom listázni akármelyiket, amióta a számlám ott van (előtte értelemszerűen azért nem, mert nem volt számla), a netbankon keresztül, bármiféle emberi közreműködés nélkül. Természetesen ez mellett van a PDF / XML kivonat letöltés, természetesen az is örökké visszamenőleg. (amúgy a nagy összeröffenés előtt a saját, helyi takarék régi netbankja is tudta ezt, ott 2002-ben nyitott számlám adatai között tudtam keresni).
Revolut, Transferwise, MagnetBank például, ahogy ügyfél vagyok.
https://iotguru.cloud
erstében kb. 10 évig lehet, de nekik most valamiért köhög a rendszerük, szóval lehet hogy egyébként menne. de hogy ne b@szd be őket valami rohadt nagy exportba, max. 90 napos intervallumot enged csak lekérdezni.
Akkor az nem a kivonat lesz, hanem a szamlatortenet. A ketto nem ugyanaz.Ja most ebben a threadben eppen a tortenetrol volt szo, akkor mindegy, kezdem elveszteni a fonalat. :D
Számlakivonat != számlatörténet. A számlakivonat a havi ciklus lezárása után keletkezett "hiteles" dokumentum logóval meg mindenfélével, amit el lehet rakni a pincébe megőrzésre. A történet meg egy sima szöveges lista az elmúlt időszakról, de nem olyan formátumban, ami bármelyik harmadik fél számára hiteles lenne.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
OTP -be benéztem, az utolsó 10 évet simán letöltheted a webes netbankon, a korábbiért vélhetően offline kell folyamodni. De 10 évvel régebbi számlakivonat vélhetően a kutyát se érdekli.
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
A fent felsorolt cegek osszesen nem leteznek annyi ideje, mint amilyen hosszu szamlamultam van egyik masik magyar penztemetonel, azert ez egy hatarozott konnyebbseg. :)
Cserébe egy-két nagyságrenddel több ügyfelük és forgalmuk van, ami azért határozott nehézség, nem?
https://iotguru.cloud
Nem, fentebb beszeltuk meg, hogy parszaz millio tranzakcio nem olyan megoldhatatlan problema. Es onmagaban tenyleg nem.
Hanem, mivel együtt lesz probléma?
https://iotguru.cloud
Evtizedek alatt osszedrotozott bughaom rendszerek. Azt hittem, errol mar volt szo. :)
Amit a "csak egy-két select" hozzáállású fejlesztőknek is lehet köszönni :-) Bár van olyan, ahol komplett számlavezető rendszer cserélődött (akár többször), természetesen az alatta lévő adatbáziskezelővel együtt úgy, hogy historikus adatok migrálása nem történt meg. (Látott már ilyet a világ...)
Tehát nem lehet megcsinálni, mert el tudsz képzelni olyan helyzetet, amikor nem lehet, függetlenül attól, hogy az elképzelt helyzeteid egyáltalán nem állnak meg a bankok nagy részére. Mire jó ez amúgy?
https://iotguru.cloud
Hol írtam, hogy nem _lehet_? Azt írtam, hogy rengeteg olyan dolog van, ami miatt nem egyszerű - amiket írtam az korábban szembe jött, most jellemzően ilyenek nem jönnek szembe - van más, amit ki kell reszelni, át kell alakítani (vagy egyszerűen csak el kell magyarázni, hogy a fejlesztő leegyszerűsített elképzelése miért ptoblémás...), hogy a nagybanki működésre szabott előírásokat maradéktalanul lehessen teljesíteni, de csináljuk :-D
Kurvára nem érdekel, hogy mekkora kupac szart álmodtál éjjel, amikor saját bevallásod szerint is az a helyzet, hogy a töredéke nem létezik a valóságban.
Ja, nincsenek nagybanki működésre külön szabályok, egyáltalán, mi az, hogy nagybank? Megint faszságokat beszélsz.
https://iotguru.cloud
Hogy is mondta Buffon? "Le style c`est l`homme meme"...
Jajj, bocsánat, amikor napokon át hordják be a válogatott szart, hogy az svájci csokoládé, akkor ilyen lesz a stílusom, születési rendellenesség.
https://iotguru.cloud
Amúgy vannak eltérő szabályok. Audit kötelezettségek főleg.
--
Gábriel Ákos
A hitelintézeti törvény ismer olyat, hogy "közérdeklődésre számot tartó hitelintézet", de az igazából minden hitelintézet kivéve az állami tulajdonban lévő bankok (MNB, MFB Magyar Fejlesztési Bank, Magyar Export-Import Bank ).
Meg ismer olyat, hogy "rendszerszinten jelentős hitelintézet", amelyek listáját az MNB hirdeti ki.
Egyik esetben sem érinti a szabályok a számlavezetéssel kapcsolatos szolgáltatásokat és itt most csak arról van szó.
De, vannak külön szabályok a rendszerszinten jelentős hitelintézetekre, tőkemegfelelés és hasonló témában, de az nem érinti a betétszámla-kezeléseket, a fizetési-számla kezeléseket. De attól még tényleg létezik olyan, hogy "nagybank", pongyolán fogalmazva.
Mindekozben volt munkahelyeden a csodas uj netbankbol nemhogy az 5 evvel ezelotti kivonatot nem lehet letolteni, hanem a 2019 decemberit sem, sot egyiket sem. Nem tudja. Nincs ilyen feature, hogy szamlakivonat. A telefonos kisasszony megigerte, hogy 2-3 munkanapon belul elkuldik emailben. Errol tudsz valamit? :D
Ja, én projekt-szakérteni szoktam ilyen helyeken, ráadásul legutoljára a Simple-nél, ami teljesen külön entitás, az ilyeneket nem tekintem munkahelynek, olyan nekem 6 éve nincs.
Röviden? Balfaszok, azért.
Hosszan? Van hatszázféle rendszerük, amit beolvasztottak a mamut zsíros seggébe; egy elbaszott adatmodelljük, ahol a számlavezető fiók a legfontosabb paraméter; de legfőképpen azért, mert a fejlesztés, az üzlet és az üzemeltetés három - egymástól igen távol lévő - épületben van és a minimálisnál kevesebbet beszélnek egymással. Többek között itt voltam mondhatni párterapeuta három éve és próbáltam kihozni, hogy a fejlesztésnek és az üzemeltetésnek össze kellene azért kicsit dolgoznia az ügy érdekében és nem keresztbe tenni direkt egymásnak.
https://iotguru.cloud
Na varjal, ha jol ertem a CV-det, majdnem 5 evig voltal Senior Java Developer illetve Senior IT Architect a szoban forgo banknal. Mi volt az oka, hogy ilyen szar lett a rendszer? (Ez most nem kotekedes. :))
Ez volt az a bank, aholarrol beszeltel, hogy keresztbefekudtek az emberek? Miert nem lettek kibaszva? Akkoriban meg boven futottak az AS/400-as cuccok, pl. a K****i. De ha tippelnem kene bizonyos netbankban megjeleno adatokbol, meg ma is, tehat onmagaban messze nem eleg megoldaskent, hogy kell egy architekt.
Az ilyeneknek mar mindegy utolag, ezert baromi sok penz implementalni azt, amit a Revolut fillerekbol megold.
Ja, hogy te a CIB-re gondolsz?
Ott leginkább azért, mert az olaszok hozták az olasz (vagy néha horvát) cuccokat, mert ugye bankcsoport-szinergia. Ennek voltak vicces mellékhatásai, volt olyan eset, hogy nem sikerült megtudni az olaszoktól, hogy mi az IBM Queue Manager neve, ami kellett volna a kapcsolódáshoz, aztán addig eszkalálódott a probléma főnökről-főnökre, amíg valami nagyfőnök visszaírt mindenkinek, hogy jöjjön be hozzá másnap a menedzser és ő kirúgja, mert valamelyik szinttől a Queue Manager neve már nem egy technikai név volt, hanem egy ember neve. Szóval remek kapcsolat volt az olaszokkal.
Volt, amit sikerült ennek ellenére partizánkodni és volt, amit nem. Egyáltalán nem technikai, jogi és/vagy szabályozási okai voltak és vannak annak, hogy nem csináltak és csinálnak meg dolgokat a bankok.
https://iotguru.cloud
Az amúgy elég vicces, hogy a 2001 óta működő Java alapú CIB Internet Bank funkcióit nem bírják/akarják átpakolni az "új" felületre. És nem extra funkciókról van szó, hanem szerintem alap kategóriásakról: számlakivonatok letöltése, rendszeres átutalások/átvezetések kezelése, devizaműveletek. Az azonban igaz (és a bankok jelenlegi gyakorlatát taglaló mellékszálhoz kapcsolódik is), hogy számlakivonatból az utolsó 6 havi elérhető, azaz időben ki kell menteni.
(amúgy lejjebb a Kapiti miért lett kicsillagozva?)
Csúnya szó. Szebb az equation :)
De banyek, nehogy már ezt annyira komoly feladatnak tekintsük. A jogi / szabályozói része bullshit (a bank amúgy is tárolja ezeket az adatokat, és meg is mutatja az üffélnek ha ezt kéri), a hozzáférés is bs, technikailag pedig picsafüst.
Az ügyfél a következőket akarja tudni a tranzakcióiról: dátum (amikor csinálta, opcionálisan amikor a bank lekönyvelte), tranzakció típus (utalás ki/be, pos, atm) összeg, másik számla és közlemény (ha van), egyenleg előtte, egyenleg utána, tranzakció díja, és kb. ennyi. Ez nagyon max 1 kB adat per tranzakció. Ezek az adatok nyugodtan mehetnek ki "archívba", miután az éles rendszerben már nincs rájuk szükség (30/60/90 nap), aztán innen meg lehet mutatni a kedves ügyfélnek, ha igénye van rá. Maga a cucc 99,9%-ban readonly, minden nap hajnal 4-kor kell rá tenni egy lock-ot és beletolni 1 perc alatt az előre előkészített, aznap archiválandó cuccot.
Most ez tényleg akkora kihívás?
Mert azt megértem, ha azt mondja valaki, hogy nincs erre tömeges ügyféligény (ami van azt olcsóbb FO/BO munkatársak basztatásával megoldani), vagy hogy az erőforrásokat más, nagyobb hasznot hozó dolgokra lövik inkább el. De hogy ezt technikailag problémát okozzon, hát bocsánat, de hadd röhögjek már ki mindenkit, aki ilyesmit állít.
Csak 10 évet húztam le bankokban és biztosítókban senior fejlesztőként és hármat architect pozícióban, mesélj még, hogy mire nem gondolok álmomban.
Amit például írtam a kivonatokról, az konkrét projekt volt egy bankban, a kivonatnak csak a nyers adatai mentek CM-be, mentéssel, archiválással, toronyórával és lánccal, ha meg kellett az ügyfélnek, akkor egy template engine elállította a PDF-et. Semmi komplexitás nincs benne, nem űrtechnika, nem kell visszahozni szinkronban a rakéták első fokozatát és párban letalpalni velük egy platformra...
https://iotguru.cloud
Neked is azt tudom írni, hogy ez egy töredék szám. Végig kell olvasni, amit írtam és rájössz, hogy ez egy TÖREDÉK. A szalagról hogy kérdezi le az ügyfél a cuccait? Ha szalagon van a tranzakciók adatbázisa, hogy dolgozol visszavalutázott dolgokkal? Ejnye no, megint azt hisszük mindenki hülye mi meg bezzeg helikoffer!
Tudom, egyik projektem napi 16-20 millió tranzakciót kezelt bankban, online egy évvel és szalagos archiválással 5 évre. Öreg vagyok én már ahhoz, hogy milliós tranzakciószámtól hasra kellene essem...
Simán, aszinkron tranzakcióval. Kimegy az adatbázisba a kérés, az adatbázis rájön, hogy ez nincs meg online, visszamegy a válasz, hogy nyugi, majd lesz, illetve szól a szalagos egységnek, hogy ugyan már húzza be valamikor ezt az adatbázis részletet, nem sürgős, de legyen meg valamikor. Az ügyfél meg majd kap egy értesítést, hogy itt a kivonata és örül neki.
De amúgy 5 év egymillió ügyféllel és csak 60 millió 1-5 kB tömörített XML, az meg 5 kB és hármas replikáció esetén is csak 1 TB adat, mint worst case, az meg lófasz manapság, már ne is haragudjál.
Miért, a papíron kiküldött havi számlakivonaton hogy történik ez meg?
Az bizony. Unom kicsit, hogy jönnek azzal, hogy "ez bank, itt komplexek a dolgok". Lófaszt komplex, sokszor csak túl van fújva, kevesebbszer meg túl van bonyolítva, aztán pillognak, ha egy másik bank tized költségből megoldja ugyanazt.
https://iotguru.cloud
Nullarol sokszor olcsobb/gyorsabb egy rendszert felhuzni, mint a 40 eve foltozott szarra radrotozni meg egy reteg szart. Ettol meg igazad van, a 20 millio tranzakcio nem kunszt, kiveve ha ezt a meglevo AS/400-as megoldasra kell felepiteni, ami mar igy is ott tart, hogy 24 oranyi tranzakcio feldolgozasa idoben 24 ora 30 perc. (Igaz tortenet alapjan.)
Persze ki lehet dobni a kukaba, ez egy egesz jo megoldas, de akkor meg is erkeztunk az eredeti kerdeshez, hogy "miert kerul ennyibe a sleep kikommentelese". Ezert.
Nem kötelező bankot üzemeltetni.
:)
Valoban nem, csak nagyon elonyos. Az IT-sek a pinceben drotozzak a fost, par huper hoborog, hogy mi-kerul-ezen-ennyi-penzbe, a usereket nem erdekli semmi, te meg szamolod a penzt valahol a tengerparton.
A havi kivonatok eltárolása tipikusan olyan dolog, ami könnyedén hozzádrótozható a 40 éve foltozott szarhoz, független rendszerként, ahova egyszer ki kell tolni indulás előtt az összes korábbi havi számlakivonatot, nyers adatként, aztán minden hónapzárás után az aktuálisat, visszafelé meg át kell kergetni az adatokat egy template engine szolgáltatáson és tényleg mindenki boldog, olcsón meg van oldva a probléma, ami nem terheli az adatbázisokat. Csak vannak helyek, ahol nem megoldani akarják a problémákat, ott minden megbeszélés 80 százalékban arról szól, hogy miért nem lehet megoldani, a maradék 20 százalék meg poénkodás és a következő megbeszélés időpontjának egyeztetése...
https://iotguru.cloud
"könnyedén hozzádrótozható a 40 éve foltozott szarhoz" - amiben vagy benne van minden, vagy nincs, ergo az archiv rendszerekhez is hozzá kell kötni, legalább ideiglenesen. Arról nem is beszélve, hogy az a "40 éve foltozott sz@r" már így is 1024-számra tartalmaz ilyen "csakhozzá kell drótozni" megoldásokat,amik mindegyike "csak kevés erőforrást és fejlesztést igényel" - együttesen meg elviszik a kapacitásokdöntő hányadát...
Tehát a kisujjukból kirázzák a plusz 1025. hozzádrótozást. Semmi bajuk nem lesz tőle, hiszen vagy az előző 1024-et sem gondolták újra, vagy megtették, és megérte megtartani. Most már csak az a kérdés, hogy a XXI. században szánalmas-e, hogy az ügyfél nem fér hozzá online az adataihoz.
:)
A bankoknál hemzsegnek a "nem és nincs más alternatíva" gondolkodású emberek.
https://iotguru.cloud
Szemelycserevel megoldhato, vagy nem is faj igazan a problema.
Na, úgy látom te is az a fajta vagy, aki a megbeszéléseken az idő nagy részében a "miért nem lehet megoldani" álláspontot képviseli. Lófaszt bonyolult ez, csináltam már ilyet.
https://iotguru.cloud
Te meg az a fejlesztő vagy, aki a saját dolgán túl nem nagyontud vagy akar látni. Nekem az is a dolgom, hogy az ilyen "ezt még drótozzuk hozzá, mert nem sok" dolgoknak a hatását minél jobban átlássam, az ezekből adódó kockázatokat segítsek meglátni - és azokra megoldást adni. A megoldás lehet a hozzádrótozás átalakításától, az elvetéséig, vagy épp a kockázatok vállalásáig sokminden. fejlesztői oldal a "ha már működik, akkor jó" mentalitást képviseli (ha elhasal, majd pecseljük), üzemeltetőként viszont a "lehetőleg ne rohadjon le" a fontosabb.
Nem, voltam architect is.
Ez tömény bullshit.
https://iotguru.cloud
Szerinted bullshit, szerintem meg általános megfogalmazása annak, hogy én hogyan állok hozzá a feladatokhoz, amikor üzemeltetői oldalról architect sapkát húzva kerül elém egy feladat. Nekem, mint üzemeltetőnek az a fontos, hogy hosszú távon lehetőség szerint stabil és átlátható maradjon a rendszer, és az entrópia elszabadulását minél jobban késleltessem, illetve csökkentsem. A fejlesztőnek mez az a célja, hogy az általa kitalált/összerakott motyó mielőbb production-be menjen, mert utána már első körben nekem (üzemeltető), illetve a sw-es támogatóknak lesz vele dolga :-P
Attól ez még bullshit. Az üzemeltetők alap hozzáállása valóban az, amit most is hozol: a változás rossz. Az ügyfél és különösen az üzlet viszont szereti a változásokat, főleg, ha abból bevétel keletkezik és pláne akkor, ha ebből a bevételből nyereség is marad hosszú távon. Akkor is jó üzletileg a változás, ha nagyon szar lesz üzemeltetni, de nyereség jön belőle még akkor is ha ezért fel kell még venni száz üzemeltetőt, akik vért hugyoznak, hogy életben tartsák a tákolmányt.
Tudod, az "üzemeltetőként felhúzom az architect sapkát" az nagyjából annyiból áll, hogy keresztülfekszel minden változásnak, amitől vélhetően több dolgod lesz, de nem nézed meg és nem is érdekel, hogy mennyi plusz bevétel jár azzal, hogy több dolgod van. Ennek a "fejlesztőként felhúzom az architect sapkát" megfelelője a kódminőség, a tesztlefedettség meg a clean code fétis, amikor addig nem megy élesbe a cucc, amíg végletekig nincs polírozva és nem zöld minden önkényesen megválasztott határértékű metrika.
És igazából az a szerencse, hogy a többi nagy bank is dugig van ilyen balfaszokkal, ezért mindegyik banki IT kurva rossz hatásfokkal dolgozik kurva drágán, kurva drága eszközökkel, a feltörekvő fintech cégek viszont rühellik az ilyen hozzáállást és előbb-utóbb letarolják a piacot. Aztán mehetsz kukoricát kapálni ezzel a fajta hozzáállással.
https://iotguru.cloud
" Tudod, az "üzemeltetőként felhúzom az architect sapkát" az nagyjából annyiból áll, hogy keresztülfekszel minden változásnak " - nagyon nem, bár sok fejlesztő, akinek halovány lövése nincs arról, hogy az ő csodálatos tákolmánya mennyi extra probléma forrása lehet - egészen addig, amíg valaki ezt a számára és az üzlet számára is érthető módon el nem magyarázza. És ami fontos, hogy a miért nem/miért hibás az elképzelés mellé minden esetben odarakom, hogy milyen módon lehetne a várható hátrányokat, problémákat kezelni/elkerülni/megoldani.
A feltörekvő babzsákfoteles fin(g)tech cégek törekszenek, de apró probléma, hogy a banki működéshez szükséges elemekből elenyészően keveset valósítanak meg, és a háttérben egy bank/pénzintézet nélkül mehetnének kapálni.
" mindegyik banki IT kurva rossz hatásfokkal dolgozik kurva drágán " - gondolom, van rá módszered, megoldásod, hogy hatékonyabban, olcsóbban, de az összes vonatkozó előírásnak megfelelően működjön egy banki IT. Ha van, akkor szerintem bármelyik általad ilyenmértékben lesajnált bank tárt karokkal fogad, hiszen a költségek csökkentése mindegyiknél kifejezetten fontos tényező. Megsúgom, mi lenne a legfontosabb a hatékony működéshez: Az új megoldások, szoftverek felhasználásának felmerültekor bevonni az üzemeltetést, illetve ahol van, a belső fejlesztőket is.
Láttál már oylan rendszerbevezetést, amikor az üzemeltetés kvázi akkor tudta meg,hogy mit kap a nyakába, amikor már eldöntötték, megvették, lefejlesztették az n+1 alkalmazást az adott cégnél addig nem használt komponensekkel, például DB-szerver, vagy épp alkalmazásszerver?
Na az ilyenek is erősen szuboptimálissá tudják tenni az üzemeltetés működését. Igen, ilyen esetben, amikor a meglévő tudásbázistól jelentősen eltérő komponenseket akarnak valahova bevinni, ott muß valamilyen mértékben keresztbefeküdni, és más megoldást szorgalmazni - vagy kompormisszumos megoldásként, ha van kellő számú ember, akkor képzést intézni a munkatársaknak - a projekt költsgkeretére. Ha ez nem megy, akkor szépen ott kell legyen írásban, hogy üzemeltetési oldalról milyen kockázatai vannak a bevezetésnek.
Mondod ezt egy mekkora ügyfélszámú bank dolgozójaként? Ember, nézz már körül kicsit a piacon, be vagy zárva egy magyar bank kis buborékjába és azt hiszed, hogy elértél mindent, amit lehet...
Hogyne, elég sok ötletem volt. Volt, amelyiket keresztül tudtam nyomni, aztán mindenki csodálkozott, hogy ez tényleg egyszerű és olcsó; meg van több, amit nem, mert eléggé komoly vesztegetési pénzeket sértett volna a dolog. Aztán belefáradtam, hogy a korrupcióval szemben próbáljam tolni a hatékonyabb IT-t, nem érte meg a befektetett munkát, ha jött egy olasz, megveregette a vállunkat, hogy jót szoptatok két hónapon át, látom, hogy olcsó, de a haverom cége fogja szállítani a szoftvert.
Persze... :D
Hogyne, többet is.
Az üzletet kurvára nem érdeklik azok a dolgok, hogy szuboptimális meg nem hatékony, meg a többi sírás. Két dolog érdekli őket: vagy legyen megtömve a magánzsebük vagy hozzon annyi pénzt a dolog, hogy magasabb üzemeltetési költségekkel is megérje bevezetni. A többi bullshit, ráadásul szerintem még naiv is vagy mindezek mellé...
https://iotguru.cloud
kiveve ha ezt a meglevo AS/400-as megoldasra kell felepiteni, ami mar igy is ott tart, hogy 24 oranyi tranzakcio feldolgozasa idoben 24 ora 30 perc. (Igaz tortenet alapjan.)
Akkor ki kell baszni végre azt a huszonéves rendszert, és olyat csinálni, ami megfelel a XXI. század informatikai standardjainak (segítek: elosztott, párhuzamos, skálázódni képes). És amilyen áron ezek az AS/400-as cuccok üzemelődnek, még csak nem is lesz drágább...
hogy "miert kerul ennyibe a sleep kikommentelese"
Nem a sleep kikommentelése kerül ennyibe, hanem az x évnyi hibás műszaki döntések meg az y évnyi technical debt. Ahol ezt meglépték régesrég, vagy ahol nem hozták meg ezeket a hibás döntéseket éveken át, ott nem kell a sleepet kikommentelni, és mindjárt nem is kerül ennyibe a dolog.
Nyitott kapukat dongetsz szerntem. :) Onnan indult a thread, hogy eleg-e kikommentelni a sleep utasitasokat. Nem eleg. Ki kell bsazni hozza a huszoneves rendszert, ami nem ket filler. Megcsinalhato siman, de nem ingyen, es nem tegnapra.
És nem simán. :-(
A legtöbb esetben az az akadály, hogy valójában senki nem tudja, hogy mit is csinál az az AS/400...
A senki az túlzás, de tény, hogy kevesen tudják.
Jártam már olyan helyen, ahol az ottani (nem AS/400 hanem HP-UX, de majdnem mindegy) szervereken futó alkalmazást már tényleg nem ismerte élő ember olyan szinten, hogy el tudja mondani, hogy mit csinál. Boldog időskorban, 80-90 évesen haltak meg a hozzáértők (legalábbis azt szeretném hinni). Forráskód se volt.
Ennél picit jobb szokott lenni a helyzet, abban igazad van.
Már csak azért is, mert az as/400 tartotta a tempót, így ma is korszerű platform szerintem. Igaz, szűk szakmai közösség műveli, de nem lehetetlen felhajtani szakit hozzá. Az viszont valós veszély, hogy eltűnik forrás a huszon éves program alól...de ez azért van, mert huszon éve mindenki megelégedésére megírt kódok is vannak, amelyeket még nem írt felül az élet, viszont a sok ide-oda állás, egyéb divatmatatás közben eltűnt a forrás. Nekem volt 18 éves programom, amit tényleg senki nem értett már - szerintem én sem - és a végén, bár baj nem volt vele, működött jól, de kockázatnak értékeltek pont azért, mert mindenki kerülgette, senki nem mert körülötte semmit csinálni, mert nem értették. Ja igen, a forrását egyszer valaki kitörölte és a backupok során kihullott a rotációból is, nagyon régi streamer kazettákon ott lehet még, csak azokhoz meg drive nincs már :) Újra tervezték a rendszer érintett kis szegmensét és megírták újra. Azóta nyugi van. Azért jót vigyorogtam, amikor ex kolléga hívott, hogy mondjam már el konkrétan mi történik benne, mert nincs meg a forrása. Nem is értettem miért gondolják, hogy pont erre az egyre emlékszem közel húsz év távlatából részletesen.
Haver mesélte nyár végén, hogy Cobol fejlesztőket kellett volna projektre rohadt gyorsan találnia de nem talált.
A harmadik sör után azon röhögtünk, hogy először a nyugdíjasotthonok környékén kell próbálkozni, de ha az nem hoz eredményt, akkor kell bérelni egy nekromantát és a helyi temetőben mehet tovább a recruiting.
Végül szereztek 2-3 tényleg öreg arcot, azok meg egész nap ültek a konyhában, kávéztak és 30+ éves sztorikon röhögtek, kb úgy, hogy "És emlékeztek, amikor '83-ban a Laca azt mondta a Bélának ..." :D
Hát...én is egy ilyen öreg arc vagyok. :D És igen, én is kimegyek a konyhába naponta többször. Skandallum. :) És még a cobol-hoz is értek. A vicc az ezekben a nyelvekről szóló vitákban, hogy semmi értelmük nincsen. Ma ezen a platformon rpg-ben nyomják a korszerű arcok a melót...de aki a platformot ismeri, az tudja, hogy hogyan működik és azt is tudja, hogy akár C-ben is nyomhatná, a végeredmény ugyanaz lesz. Akármelyik nyelven ugyanazt meg tudom valósítani így vagy úgy. Ez igaz az AS/400 vagy iSeries platformra.
Mondjuk pl. Linuxon én abszolút C párti vagyok, de ennek az oka az, hogy abban otthon vagyok, azonnal hadra fogható. És hát nem látom be, hogy ha egy környezetben nekem hosszan le kell ülnöm, miért hasznosabb a C++ vagy tásai, mint a C. Vagy akár a cobol. De ez lehet, hogy a koromból adódik. :)
Nem azon volt a hangsúly, hogy kávézni mernek, hanem hogy annyira kicsi (maradt) a szakma ezen ága, hogy mára közismert mítoszok és legendák alakultak ki, amiket elég kb. a sorszámukon említeni, mint a törpés viccben és máris röhög mindenki :)
Ez messzire visz. :)
Még azért nem olyan ritka, de már ritkulunk. :)
Nem visz messzire. Én vagyok C párti és nem zavar, ha más más párti. Végülis a lényeg az, hogy a feladatot meg tudd oldani, persze azon eszközrenszeren belül, amit az aktuális munkáltató rendelkezésedre bocsájt.
es nem tegnapra
Nem is kell "tegnapra"!
A "kedvenc" bankomnál 18 évvel ezelőtt (2002-t írtunk) is már ment gyakorlatilag éjjel-nappal a tranzakció feldolgozás és a netbank. Szombat hajnal cca. négykor úgy döntött a cégünk, hogy az ugyanazon banknál vezetett magánszámlámra át kéne utalni egy kis lóvét. Netbank fellő, átutalás, következő percben pittyeg az SMS, megjött a zsé, ha kedvem lett volna lemenni egy ATM-hez, ki is vehettem volna az egészet.
Semmi nem akadályozta meg a konkurenciát, hogy észlelje, mit tud a másik bank, és lemásolja. 18 komplett éve lett volna rá! Nem "tegnapra"...
De erted, a vita nem onnan indult, hogy ki mekkora tech debt-et tudott osszehordani rossz dontesek miatt, hanem hogy "ki kell kommentelni a sleepet". :D Senki nem mondta, hogy a mostani helyzet jo, csak mar 20-40 eve gorgetik mar meguk elott a ganajt a bankok, es most utolag rohadtul nem trivialis eltakaritani.
"ugyanazon banknál vezetett magánszámlámra át kéne utalni egy kis lóvét" - bankon belüli átvezetés nem fordul meg a GIRO-nál, ezért elvileg (szinte) bármikor megtörténhet. Számlanyitás (meghatalmazottként lettem felvéve hozzá), még a papírok zörögnek kifelé a nyomtatóból, de a mobilbankon már látom, átvezetés, készen van, és a számlatulajdonosnak már jött is az sms, hogy jóváírás érkezett a számlájára.
Te tudod. Olvassad el az eredetit. Csak a sima alaulbecsült forint utalásos "hup bank" esetében volt évi 300 millió rekord. És után írtam még, hogy ehhez mi jön hozzá...becsüld meg, mekkora a végeredmény. Az igény nem aszinkron tranzakció volt. És nem kivonatot akart kapni. Én tényleg elolvasnám a helyedben azt, amire válaszolok, pláne ha ilyen tahó stílusban le akarod teremtenia másik felet.
Hidd el, nem haragszom, de ez a mondat nem passzol a szövegkörnyezetbe tartalmilag sem. Hogy pék farkába jött ide xml?! Meg mi ez a 60 millió 1-5 kb izé?!
Tényleg analfabéta vagy? Az adatokon feldolgozás fut, a kivonatot meg elolvassuk. A visszavalutázott tétel az aktuális kivonaton jelenik meg múltba mutató valautanappal. De a futások során a tétel valójában a valutanap által mutatott naphoz tartozik. Ha nem érted a nem kis difit, kérlek ne válaszolj!
Ezután a mondat után vannak kétségeim, hogy te valah bármi fajsúlyosat csináltál-e bankban. Egyetlen piaci szereplőt sem szabályoz annyi jogszabály, mint a bankokat és ez így van jól. De ettől azért tényleg kicsit bonyolult lesz. ÉS persze túl is fújnak dolgokat, ahogy mindenhol máshol is. Szépen nyugodjál meg, mert ha az az ér elpattan a homlokodon, akár el is vérezhetsz hupozás közben!
Miért kellene ettől nekem hanyatt esnem? Mondom, volt banki projektem, napi 16-20 millió tranzakcióval, egy év online, 5 év szalagon, az 6-7 milliárd rekord volt online, és 25-30 milliárd szalagon. Tényleg nem értelek, hogy mi ezen a nagy dolog...
Egy éve hobbiból gyűjtögetem a MÁV valós idejű adatforrásából az adatokat, ott már 100 millió rekord van... ásít, ennyi rekord manapság lófasz sem.
Ja, és? Csak mondottam volt egy megoldást, amiben részt vettem. De egyáltalán nem komplexebb az, hogy konkrét tranzakciótörténet is lekérdezhető legyen.
Oszt? Nem látom a lehetetlenséget a dologban.
Kételkedj. Attól nekem nem lesz rosszabb. Én viszont azt látom, hogy próbálod valami nagy dolognak beállítani, hogy egy kis hangyafasznyi magyar banknál szopsz évek óta, meg százmilliós tranzakciószámot felhozni, hátha attól majd hanyatt esnek...
https://iotguru.cloud
Tehát kell egy archív rendszer, amibe Ádám-Éva és az öreg diófa óta minden ott van - ja, nem, mert van "néhány" jogszabály, ami ezt korlátozza, ergo kell belőle gyakorlatilag folyamatosan takarítani egyrészt a "meddig tárolhatod" miatt, másrészt meg a GDPR okán is ugyebár...
Kell az éles rendszerből az idővonal "másik végén" etetni - sajnos az nem megy, hogy "x napnál régebbik oda, annál frissebbek ide", úgyhogy ez is bonyolítja a visszakereséshez az adatok áttöltését, mint ahogy az is, hogy az éles számlavezetőben változhat sokminden, ergo az archiv rendszerbe történő adatátadást is folyamatosan utána kell húzni (n+1. éleshez hozzádrótozott dolog ugye...)...
Aztán kell üzemeltetni adott SLA-val, éles üf.adatok miatt a hozzáférés szabályozása és naplózása az élessel megegyező szinten kell, hogy legyen, satöbbi.
Meg _lehet_ csinálni. Szoftverfejlesztői oldalról valóban nem nagy kunszt - viszont a teljes IT-rendszerbe beilleszteni, fenntartani már pirinyót bonyolultabb - és nem olcsó. Igen, tudom, az üzlet részéről, pláne, ha élesbe ment a szolgáltatsá senki nem fogja kimondani,hogy baszics, ez a szolgáltatás qrvára nem éri meg... Vagy ha igen, akkor is n+1 év és egy rakat elköltött zseton után - és nem úgy, hogy eredetileg is baromság volt, hanem "változtak az ügyféligények"...
Persze, ultimate érv, ha valami nem akarunk megcsinálni, akkor GDPR... csak tudod, hibás érv itt, mert jogos üzleti érdeknél és jogszabály által előírt adatmegőrzés esetén pont nem számít, ez meg az, ráadásul semmiben nem különbözik attól az adattól, amit amúgy is elő kell bányásznod valahonnan, ha kell az ügyfélnek, tehát tárolod amúgy is, csak valami elbaszott rendszerben, horrible dictu, papíron. Ne akarjál már hasba akasztani ilyen faszságokkal, kérlek. Az is szégyen, ha komolyan gondolod és az is, ha nem.
Hogyne lehetne, elég sok banknak sikerült is, gondolom nem tudták, hogy mekkora szívás lenne, ha egy zeller lenne náluk az üzemeltető architect sapkában. A többi mondatod meg bullshit, tartogasd a banki megbeszélésekre, hogy mit miért nem lehet megcsinálni.
https://iotguru.cloud
ezek a szamok atlagpistinek hangzanak soknak. :)
megneztem, az elmult egy napban (hetvege van ugye, tehat pentek estetol szamolva) az egyik belso ingestion rendszerunk (ami adatot mozgat A es B kozott, hogy B-ben [a mi rendszerunkben] lehessen queryzni) 10 milliard soron ragta at magat, volt olyan forrastablank amiben ~204 millio sor volt.
ez csak a raw adat, nem queryk eredmenye vagy ilyesmi...
Csak vas és sávszélesség (vas-storage/vas-vas) kérdése az egész :-D
nem is hiaba csak 100GbE linkekbol all a backbone :-)
Teljesen új rendszer, messze nem egy bit átállítása. A jelenlegi átutalási rendszer batch jellegű, az átállás nem annyiból áll, hogy a jelenlegi giro kör intervallumát lerövidítik.
A jelenlegi rendszer is csak munkaidőn kívül batch, munkaidőben OLTP. Szerű.
Azért az IG2-t maximum "-szerű"-nek lehet nevezni :-)
Nem az, a napközbeni is batch 2 óránkénti ciklusokban...
A történelmi hűsék kedvéért mondjuk el, hogy amikor a GIRO indult, a franciák - akiket de utáltam akkor! - real time rendszert terveztek. Utalsz, az beszalad a giro-ba, könyvelődik a bankodnál és az mnb-nél és megérkezik a célbankhoz, ahol könyvelődik. Csak ezt nem merték bevezetni, nem emlékszem miért, így lett egy kiherélt és kötegelt feldolgozást erőltető vacak. Az OTP ezt sem tudta megugrani, a finisben kapott két hét laufot, mert sehogy nem állt. Csak mert ugye a magyar bank az otp, ahol ma sem tudok nyíregyházán - nem falu - úgy rendelkezni a budapesti V. kerületben nyitott számlám felett, mint egy rendes banknál.
Na ja... Azért az utalás lépéseit erősen leegyszerűsítetted :-) Bőven van pacsizás :-) a kuldő - giro - fogadó útvonalon oda-vissza néhányszor, mire minden a helyére kerül, és a fogadó oldal el tudja küldeni a beérkezett összeget :)
OTP... Anno volt szerencsém Miskolcon nyitott számlával rendelkezni, és Bp.-en szerettem volna készpénzt felvenni a számlámról. Érdekes volt a párbeszéd:
-Hol vezetik a számláját?
-Miskolcon.
-Az melyik megye?
-...
Oké, megmondtam neki, hozzátéve, hogy ezt azért illene tudni.
Két-három héttel később hasonló kör, csak most egy idős ügyintéző volt az ablak túloldalán, a múltkori fiatal leányzó hátul csinált valamit. Beszélgetés az "Az melyik megye"-ig azonos, a múltkori fiatal leányzó ekkor nézett fel, és kezdett kuncogni, mire az idősebb megkérdezte tőle, hogy "Te mit nevetsz?" Mire a lány: Majd a fiatalember elmondja :-) Elmondtam...
Aki a teljes folyamatra kíváncsi, olvasson szabványkönyvet! :) Ez a Miskolcos sztori jó! :)
Nem vagyok rá kíváncsi. Már nem :-D Elég, ha azt fejben tudom tartani belőle, amit kell...
Tőlem meg azt akarták megtudni, hogy melyik fiók legyen a számlavezető. Megkérdeztem, hogy van-e bármilyen praktikus jelentősége. Azt mondták, nincs. Erre megkértem hogy válasszon egyet. Mondta, hogy csak én dönthetek. Közöltem, hogy képtelen vagyok alap nélkül dönteni. Végül megkért (szinte könyörögve) hogy válassszak már egyet, majd a választásom a munkahelyemhez közeli fiók lett. De ma sem tudom, hogy minek.
(de a kedvenc ügyintézős beszélgetésem az volt, hogy az ügyintéző sosem hallott card fraud detectionről, és fogalma sem volt hogy pontosan milyen és mikori árfolyam(ok) váltódnak majd ha magyar forintos bankkártyával fizetek az EU területén).
arch,ubuntu,windows,android
zbook/elitebook/rpi3/nokiax6_DRG_sprout
Több oka is volt. Az eredeti Giro rendszer elosztott rendszer lett volna, gyakorlatilag nem az egyes bankok, hanem akár bankiókok is rácsatlakozhattak volna (valamikor 1991-92-ben tervezték a rendszert, nagyon sok banknak nem volt országos hálózata, így könnyebb lett volna, ha több helyen csatlakozhatnak az országos rendszerre), az elszámolás pedig nettó elszámolási rendszer lett volna, nap végén szépen kiszámolták volna, hogy ki kinek mennyivel tartozik, amit aztán majd rendeznek. Aztán pár év alatt megváltozott a rendszer, a bankok kiépítették az országos hálózatukat, és nagyobb kontrollt akartak a saját pénzforgalmuk felett, így a sokpontos csatlakozás helyett egypontost akart mindenki (nesze neked hálózati adatforgalom méretezés), természetesen a technológia is váltott - eredetileg X.25 volt tervben, ezt pár év alatt rohamléptekben váltotta le a TCP/IP -, ráadásul időközben volt egy-két bankcsőd (Agrobank, stb), és a bankok azt mondták, hogy inkább bruttó elszámolás legyen.
A hálózati gondok miatt első körben a BZSR floppyk továbbításával zajlott, utána lett aztán online, szóval elég érdekesen alakult a GIRO története :)
+1
A legtöbb bank meg tudta volna ugrani, hogy a ciklust lerövidíti 1 percre, vagy 30 másodpercre vagy ilyesmi. Viszont azt, hogy ez menjen 7x24-ben, meg azt, hogy ez menjen 5 másodperces ciklusokban, nos, azt nem tudták könnyen megugrani a jelenlegi rendszernek adott +1 pofonnal. Ezért kellett egy csomó helyen új rendszert (vagy rendszereket) bevezetni, meg ezeket a többi rendszerhez illeszteni.
Szerintem nem jól érzed...
Kb. 1 éve azt olvastam, hogy tavaly nyáron indul.
„Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat.”
"Az eredeti tervben szereplő július 1-től már élesben ment volna a rendszer, de ezt 8 hónappal elhalasztják, hogy minden bank megfelelően fel tudjon készülni. […] A piaci szereplők oldalán azonosított kockázatok miatt a Pénzügyi Stabilitási Tanács 2019. május 28-i ülésén úgy döntött, hogy a pénzügyi stabilitás fenntartása, az elektronikus fizetésbe vetett bizalom megőrzése és a szolgáltatással tervezett ügyfélélmény elérése érdekében az ügyfelek számára az azonnali fizetés 2020. március 2-ától lesz elérhető." - https://www.portfolio.hu/uzlet/20190531/breking-elhalasztottak-az-azonn…
MERT AZ Ü G Y F É L É L M É N Y ! ! !
:D :D :D :D
~ubuntu, raspbian, os x~
Azért érdekes, hogy funkció nélküli várakoztatások kikapcsolása ennyire sok fejlesztést igényel.
nem az 5 masodperces SLA a nehez ebben az egesz "azonnali atutalas" tortenetben, hanem a 7/24 rendelkezesre allas az ugyfelek fele. a banki szamlavezeto rendszerek nagy resze by design alkalmatlan erre (napi, havi zarason kell ragodnia, stb-stb.), ezert mindenfele workaround-oakt kellett takolni korejuk a legtobb helyen.
a bankkartyas fizetes valoban megy ejjel-nappal, csak az altalaban a core szamlavezetestol fuggetlen rendszer.
_m.
Igen, azt észreveszem a furcsábbnál furcsább egyenlegekből, amikor hétfőn aztán összefésülik a kettőt... De megértem, mert bankkártyák még csak harminc éve vannak Magyarországon, szóval még nem egészen tudtunk alkalmazkodni ehhez az újdonsághoz.
Magyarorszagon pedig egesz jol alkalmazkodtunk, latnad mi van a Fejlett Amerikaban. :)
Az amerikaiak hozzáállását a bankkártyákhoz legjobban a contactless magstripe létezése jellemzi. :P
Jaja, azert mondom kar fikazni a magyar helyzetet, amikor az USA-ban siman van kolaautomata, ami stripe-only, raadasul ha egyszer lehuztad a kartyat, akarhany kolat kerhetsz akarmeddig, amig meg nem nyomod a finish gombot. Vagy meg nem nyomja egy becsuletes jarokelo a finish gombot, miutan a kevesbe becsuletes jarokelok mar elvertek parszaz dollart kolara a kartyadrol. :D
Azért az 5s múlva "elkölthetően" ott legyen a számlán sem piskóta.
Egy csomó helyen úgy működik a bankkártyás fizetés, hogy:
- a fizetés előtt egy T1 időben a bank elárulja a kártyatársaságnak, hogy mennyi pénz van az ügyfél számláján az adott pillanatban
- fizetsz T2 időben, a kártyatársaságnál meglévő pénzed lecsökken, de a banknál meglévő pénzed érintetlen marad
- a kártyatársaság szól T3 időben a banknak, hogy az ügyfélnek mennyivel van kevesebb pénze.
Egy rakás banki működés arra épített korábban, hogy T1 és T3 között (tipikusan este és reggel között) az ügyfél úgyse tud csinálni semmit a bankkal, nem tud pénz kivenni a bankkártyán kívül más csatornán, szóval ez így pont jó, ha T1 mondjuk tényleg este van T3 meg másnap hajnalban (meg bonyolultabb a könyvelések miatt a helyzet meg ilyenek, de azt most mindegy).
Na, ezt kell átalakítani úgy, hogy _mégis_ változhat mindkét helyen a kedvesügyfél egyenlege éjszaka is. És ha volt 100 ezer Ft-ja, akkor ne tudja a bankkártyájával és az azonnali átutalással is elkölteni. Ezt nem tudod csak úgy egyszerűen belepatkolni a rendszerbe (különösen, ha a kártyatársaság és a bank között mondjuk FTP-n megy a kommunikáció (nem, nem SFTP-n, és igen, láttam már ilyet)).
Egy rakás banki működés arra épített korábban, hogy T1 és T3 között (tipikusan este és reggel között) az ügyfél úgyse tud csinálni semmit a bankkal, nem tud pénz kivenni a bankkártyán kívül más csatornán
Nade ez a bank sara. Ők álmodták meg ezt a zseniális rendszert, most akkor visszanyalt a fagyi.
Tegyük hozzá, hogy más bankoknak már 15+ éve sikerült jó rendszert álmodni (ami lehet, hogy más sebekből vérzik, de legalább nem architekturálisan van elbaszva): az én egyik bankom már 2003 körül tudta azt, hogy éjjel-nappal lehet bankon belül átutalni, és a frissen megérkezett zsetont a címzett akár rögtön ki is vehette az ATM-ből.
Egyetértek, ez bizony a bankok meg a kártyatársaságok sara. De ez nem jelenti azt, hogy a rendszer könnyen, gyorsan és fájdalommentesen átalakítható. Azt jelentheti, hogy Téged nem kell, hogy érdekeljen :-D
Hát igen: az elmúlt 25-30 évben, amióta bankkártyák vannak, fel kellett volna ébredjen bennük a gyanú, hogy valamikor a boldog békeidők is véget érnek.
Amelyik magyarországi banknak az elmúlt 15-20 évben nem esett le, hogy itt előbb-utóbb olyan rendszerre lesz szüksége, ami éjjel-nappal tud tranzakciókat tolni, az egy álomvilágban élhetett...
Ebben a rendszerben hogy kezelik azt le, ha van az adott számlához két külön kártyatársaságtól debit kártyám?
Sehogy, itt minden kártyának saját számlája van, azt tudod kivenni/elhasználni a kártyával aznap, ami reggel is megvolt azon a számlán. Emlékszem ilyen fos rendszerekre az ezredforduló korából, jellemzően a limiteket sem tudtad variálni napközben (esetleg sehogyan se, majd a bank megmondja, hogy mennyit költhetsz egy nap)... hát valahogy inkább másmilyen bankot választottam :)
Nem tudom ezt honnan veszed, de az tény, hogy az én számlám egyenlege azonnal megérzi ha vásárolok. Ezt SMS üzenetben bizonyítja is. Mi több, ha reggel az egyenlegem 1 HUF, de délelőtt 10-kor jön pénzem valahonnan, mondjuk 500.000 HUF, akkor én simán tudok vásárolni 500.001 HUF-ért. Ha hitelkártyám van, akkor 500.001+hitelkeret összege HUF-ért.
"a limiteket sem tudtad variálni napközben" - tippre nem a bank, hanem harmadik fél authorizált, és a limit a partnernél került beállításra/módosításra, amit a bank és az authorizálást végző harmadik fél közötti megállapodás szerinti sűrűséggel és költség mellett volt módosítható.
Khm... Szerintem kérdezd meg hozzáértőktől, hogy miben különbözik az IG2 meg az IG3 feldolgozási folyamat...
Sikerült a cronból futó átutalás.sh-t berakni backgroundba? :)
Ennél egy pöttyet összetettebb a dolog...
Csodalatos amugy, hogy mennyi baromsagot lehet osszehordani, ha az ember nem gondol bele rendesen egy munkafolyamatba, csak kommentel egyet a levegobe.
Ezt nyilván már megszokták azok, akik non-IT emberekkel kell sokat dolgoznunk. De hogy egy IT portálon is ezzel kell találkozni, az azért elgondolkodtató.
Az IT-sok tipikusan a legrosszabb felhasználók :-D
Amugy az ertetlenkedo kommentek gazdaitol megkerdeznem:
Vagy rövidebben:
:D
trey @ gépház
..és mindezt cobolban
~ubuntu, raspbian, os x~
Nem, de egy megbízható tranzakciós rendszer nem a világ legbonyolultabb dolga. Persze lehet úgy csinálni, hogy az legyen de valahogy nehezen hiszem el úgy, hogy a telefonomon a (magyarországi) banki alkalmazások egyértelműen a legmegbízhatatlanabban működő programok.
Persze, tudom ez csak az app hibája, a háttérben minden szuper. Az otp hálózaton nyitottan lógó piwik, rdp csak véletlen és hsts-t meg csak kalandvágyból nem használnak...
Onmagaban lehet, hogy csak egy kozepesen bonyolult dolog, de egy meglevo, nem erre tervezett architekturat atalakitani mar nehezebb.
Nnna, ezt emeli be nehezen a közönség többnyire....
"...dehát csak azt kérem hogy a busz legyen vizibusz, nehogymár egy hétig tartson, a busz itt van készen...."
https://derrickesharry.blog.hu/2017/03/26/a_csak_egy_mezot
Nem tudom, nekem ami mobilos app fent vana telefonomon, az teljesen jól működik. Bár csak az egyik olyan, hogy a futó feladatok at lapozgatva nemmutatja meg az ablak eredeti tartalmát, hanem kitakarja egy fehér téglalappal...
Az, hogy mi "lóg ki" egyik vagy másik bank hálózatából a nagyvilág felé olyan, aminek nem (biztos hogy) kéne, annak a banküzemhez relative kevés köze van.
Lehet, hogy a háttérben jól működik, de én csak abból tudok ítélni, amit látok/tapasztalok: jelenleg 8mp-be telik az utolsó 10 tranzakció betöltése, max 1 hónapot lehet lekérdezni, pár napja órákig "hibás jelszó" üzenetet dobott weben, appban meg internet kapcsolat hibát, átláthatatlan még a banki dolgozók számára is nehezen értelmezhető számlakonstrukciók. Az egész számomra jó példázata annak, hogy mi történik, ha egy iparágban hiányzik a valódi verseny az ügyfelekért.
Ha látok egy éttermet ami előtt koszos ruhában cigizik a szakács, akkor szerintem jogosan feltételezem, hogy a konyhai tisztaság sem tökéletes.
>Nem, de egy megbízható tranzakciós rendszer nem a világ legbonyolultabb dolga.
Valóban nem, nem véletlenül rántotta össze nulláról röhögve a sajátját a Revolut vagy bármely más hasonló fintech cég.
A gond itt inkább azzal lesz, hogy összetett, kiterjedt céges struktúrákról, munkafolyamatokról van szó csomó legacy örökséggel ami egyszerűen nem kidobható. Hiába írsz te meg faszán egy tranzakciókezelő rendszert ami a GiroInstanthoz csatlakozik, annak még tartania kell a kapcsolatot a Bank n+1 szutyvadék belső rendszerével amire a birobotok be vannak tanítva, valahogy hozzá kell igazítani a bank könyvelési folyamataihoz, kezelni kell tudni a cashflow-t rendesen éjszaka is, mindeközben meg kell felelni mindenféle szabályozásnak, mert bokáig ott van a felügyelet lába a seggedben folyamatosan. Ja és közben persze mennie kell a régi rendszereknek párhuzamosan, magas rendelkezésre állással.
A fintechek azért "szárnyalnak" úgy, azért nyújtanak apróból sokszor jobb szolgáltatást, mert nekik sokkal kevesebb mindennek kell megfelelniük, illetve nincs meg a sok legacy örökség cégstruktúrában, egyebekben.
Itt gyakorlatilag négykilencest várnak el a szolgáltatásra... Nomostan ez ahhoz képest, hogy az IG2-re milyen SLA-t kellett tudni, böszme nagy ugrás.
A rendelkezésre állásról tudnék mesélni CIB ügyfélként. Volt hogy a kártyámat sem tudtam használni órákig, ráadásul külföldön. Szerencsére volt nálam egy másik kártya (Erste), pont ilyen eshetőségre. Egyszer az is előfordult, hogy nem fogadta el kódomat. Bementem bankba, előadtam a problémámat, mondták fizetnem kell érte, mert biztos elfelejtettem. Erre adom meg a gépnek (bent a bankban) az új kódot: sikertelen módosítás, ez a jelenlegi kód. Kiküldtek bank elé kártyával, hogy próbáljam meg újra. Nem ment. Utána elnézést kértek és ingyen cserélték. Ugyanígy egyszer megadtam kártyának valami 50e Ft limitet, ki akartam venni 50e Ft-ot és nem tudtam. Bank ügyfélszolgálata azt mondja adjak meg legalább 5-10e Ft-al nagyobb összeget limitnek, mert ez ismert hiba a rendszerben. Ezek után elképzelem milyen tákolmány rendszerük van (amivel valószínűleg nincsenek egyedül, legalábbis amit hallottam olyantól, aki fejlesztett ilyen rendszert másik banknak)
Ja és ha valaki megkérdezné miért nem hagyom ott ezt a szerencsétlent: államnak is végzek munkát és a bürokrácián keresztül átvinni egy számlaváltozást szinte lehetetlen. Címemet kb 3 év alatt tudták megváltoztatni sokadig próbálkozásra, de szerintem még egyes szervezeti egységektől még mindig megy régi címemre levél.
Ja és ez a delay comment annyira nem vicces dolog, mindenki találkozhatott vele ha volt BME-s Neptun gyűjtője régen és nem ahhoz a bankhoz szegődött, akinek a papírját beletették az indexbe az egyetemen az első tájékoztatáskor. Valamint hozzátették, hogy igen ajánlott annál a banknál számlát nyitni, mert BME nála van és más banktól, akár 1 hét is lehet míg jóváírják az utalást..
Én azért megpróbálnám a számlamódosítást - ezeket a copásokat elkerülni bőven megéri 2-3 hónapig két számlával élni.
Az, hogy a BME-s nemtpun össze volt drótozva a számlavezető bank elektronikus felületével, de a máshonnan érkező jóváírásokat nem tudta kezelni (és kézzel csinálták), ez a neptun-számlavezető rendszer közötti kapcsolatot kezelő komponens hibája. (IG2-vel már sok-sok éve legfeljebb a következő banki napon ott van a kedvezményezett számláján felhasználhatóan az átutalt összeg - az, hogy onnan a BME-s könyvelés mikor és hogyan emeli át a tranzakciókat, és könyveli le a megfelelő helyre, az nem a bankközi adatcsere sara.
Erste volt ennek a banknak a neve, nyugodtan kiírhatod, nem visz el a gestapo.
Csak azért nem akartam kiírni, mert nekik is voltam ügyfelük később és meglepően korrektek voltak. Például mikor volt az a botrány, hogy egyes bankok díjat kértek (valami 5e Ft-ot) a számla megszüntetéséért, akkor ők nagyon gyorsan, korrekten, mindenféle díj nélkül megszüntették a bank és bróker számlámat is.
Attól még tény marad, hogy az egyetemi bankszámlánál kilobbizták h. a felvételi tájékoztató borítékban az ő brossúrájuk legyen ott, ne a többieké. Direkt szürke maradjon az a kérdés h. másnál is bankolhatok-e vagy muszáj náluk nyitni h. ne legyen fennakadás a szeptemberi évkezdéskor? Főleg mikor az embernek vidékiként albérletet és minden mást kellett intéznie még, pont ezt rizikózza be a kezdéskor.
Igen, ez nem volt tisztességes szerintem sem.
Csak éppen nem az erste volt tisztességtelen. Mikor jövünk rá, hogy a versenyben a versenyzők mindig elmennek a határokig? Csak az hibázott a fenti esetben is, az volt tisztességtelen, aki a határokat kitolta az erste előtt.
> ...ki akartam venni 50e Ft-ot és nem tudtam. Bank ügyfélszolgálata azt mondja adjak meg legalább 5-10e Ft-al nagyobb összeget limitnek...
OFF
Volt egy film, amelyikben úgy indult a bonyodalom, hogy a srácnak 20.12 $ pénze volt a számláján, ki akart venni egy huszast, de a 20 $ + tranzakciós díj több volt, szóval az ATM elutasította, ekkor bement, persze egy rablás kellős közepébe.
/OFF, csak eszembe jutott, jó film volt amúgy.
Debian - The "What?!" starts not!
http://nyizsa.blogspot.com
Engem az érdekelne, eleve őrülten hiperaktív zeller társunknak miért van ilyen kínos szófosása.
:)
Hát, ezt mondhatta volna szebben, kis lovag, de azért...
Mert a sok okos böfögéstől hasmarsot kaptam :-D
Csak várjatok ki, míg én kezdek válaszolgatni 😀
:-D
A repertoárod kimerül egyetlen harmatgyenge blöffben, vagy tényleg van mire várnunk?
:)
Szerintem elég sokat találkozott IG1/2/3 dolgokkal... Hogy mennyit mesélhet róla, az más kérdés.
Mire vagy kíváncsi? Bank vagy egyéb szereplő részére specifikus dolgokról nyilván semmit nem mondok, de a rendszer egészéről szívesen mesélek.
Teljesen kielégít, amiket írtál. :D Volt olyan időpillanat, amikor a hozzászólások húsz százaléka zelleré volt, kissé sáros zöld stílusban, az önismétléstől sem tartózkodva. Tényleg úgy dőlt belőle, mint a fos. Ez zavart.
:)
Hát... oké :-)
Amíg nincs a Marsnak mágneses mezeje addig fölös erről beszélni.
ps.: lol ezt most nem értem, eléggé 100% hogy nálam van a gubanc de nem ebbe a topicba szántam az írást, mégis ide került.
Na ez zsír! Soha többet nem akarok olyat, mint most karácsony környékén... 6 napig nem lehetett utalni. Rothadt ideges voltam. Szerintem ennek a 6 napnak konkrétan GPD-n százalékban mérhető hatása volt.
Az pl. egy elég jó kérdés, hogy mi lesz a bankszünnapok és az azonnali fizetések viszonya, mert az eredeti SEPAInst-hez képest a HCTInst-nek nem része a logoff-logon a szereplők részéről...
Na erre én is kíváncsi vagyok...
Az emberiség a matéria Isten rötyijében.
:)
Akkor most végre kiderül, hogy MÁK mikor utal ténylegesen és ki ült eddig hétvégén még a pénzemen?
(péntek esete elküldi a MÁK vagy csak hétfőn reggel?)
Ezt kell nézni:
https://www.giro.hu/letoltes/bkr-uzletszabalyzata-2019-01-01
A mellékleteket nézd a 98. oldal környékétől, abban vannak az időzítések. Az egész abból a korból származik, amikor még minden egyes banki átutalással emberek foglalkoztak gépek helyett, az időzítéseket is így nézd...
A pénzed egyébként ilyenkor részben még a MÁK saját számláján, részben a saját bankod MNB-nél vezetett számláján, és részben a Te számládon van (de olyan állapotban, hogy még úgyse férsz hozzá). Nyugi, ilyenkor nem kamatozik senkinek sem, az elszámolási számlák tipikusan kamatmentesek (ami akkor igazán érdekes helyzet, amikor egyébként negatív a kamat :D).
Én ettől azt várom, hogy március 2-án, 3-án egyáltalán nem fog működni sem az átutalás, sem a netbank, sem a mobilapp, majd 4-én, 5-én talán infót tudsz lekérni, ha nem timeoutol el, 6-7-én nyomokban mennek majd a tranzakciók és belépni is be lehet esetleg normálisan, és majd 2-3 hét múlva talán már tényleg működni fog.
Az utóbbi időben akármilyen change volt a bankoknál bármilyen téren, az tuti hogy szarul sült el.
"Sose a gép a hülye."
Hát igen, nagy meglepetést nem okozna, ha így lenne...
Vagy a Sárisápi Takarékpénztár egy nappal korábban bevallja, hogy mégsincs kész, erre mindenki más is fellélegzik, hogy hát tulajdonképpen izé...
Nem tud ilyet tenni.
Egyrészt mert nincs Sárisápi Takarékpénztár (meg hasonló nevű sem, tavaly a takarékszövetkezetek egyesültek a Takarékbankban, lásd: https://www.takarekbank.hu/ertesites-osszintegracios-egyesulesrl). A Takarékbank a GIRO-tag, TAKBHUHB BIC-kóddal, nézd meg a korábban linkelt hitelesítő táblában.
Másrészt a rollout ütemezése nyilván nem olyan, hogy ezek 1-2 nappal az indulás előtt derüljenek ki. Egyrészt a rendszer tesztelése zajlik már tök rég óta (legalább másfél éve), másrészt az indulás előtt ~1 hónappal kiadott hitelesítő táblába bele kell kerülniük azoknak, akik ténylegesen indulnak, mint azonnali-fizetés-képes entitásnak, úgyhogy legkésőbb február elején ki fog ez derülni.
Úgy legyen, ámen. (Off-topik: Mondjuk a takarékszövetkezetekhez még hadd tegyem hozzá, hogy önként egyesültek. Ugyanis az volt a szabály, hogy ha nem egyeznek bele önként, akkor is pontosan ugyanaz történik, csak még jobban megszívják.)
Szerintem sem lesz minden zökkenőmentes az indulás, sosem az, de nagyon komoly problémákra én nem számítok ezzel kapcsolatban. Meglátjuk :-)
Összes lóvét kp-ban kivenni számláról, párnacihába bevarrni. Ha már működik minden faszán, lehet visszatolni a számlára.
Hint: erteknaposan kell utalni, az IG2-n fog menni ;)
Gondolom már egy ideje párhuzamosan fut a most meglévő rendszer, és a még nem élesített azonnali átutalásos rendszer. És egy ideje minden jól működik, azért élesítik. Legalábbis remélem :) Aztán csak annyit kell majd tenni, hogy átállnak az azonnali utalásos rendszerre, a másikat meg lekapcsolják.
Szerintem egy IT rendszer se így működik. A banki IT meg aztán főleg nem!
amikor az szrt vezette be az új rendszerét, ott pl. fél éves párhuzamos futás előzte meg az élesítést. és még így is rákerültek az index címlapra. :)
Az lett volna a meglepő, ha az szrt elkerülte volna a címlapot... ami ott megy, az alapján erre esélyük sem lehetett.
Röviden: Nem. Hosszabban: nagyon nem.
jelenleg egyszerre fut az éjszakai átutalás, a napközbeni átutalás, és az azonnali átutalás is. utóbbit ugyan próbaüzemnek hívják, de igazi pénz megy rajta, szóval ez nem csak egy sima párhuzamos tesztüzem. annyi megkötés van, hogy az ügyfelek pénzét a bankok jelenleg nem az azonnalin keresztül küldik. ehhez nem kell túl sok pénznek forognia a rendszerben, de ebből a szempontból mindegy, hogy egy tranzakció egy forintot, vagy háromszázmilliót fog átvinni.
de ahogy már ügyfélpénz is megy majd az azonnalin, nem fogják lekapcsolni a másik kettőt.
Ez akkor lenne igazán jól kivitelezhető, ha a cél az lenne, hogy az azonnali átutalások eredménye minden esetben ugyanaz legyen, mint a jelenlegi IG2-es átutalások eredménye. Ez nem így van, így a párhuzamos-futtatós + összehasonlítós módszer nem működik.
Amúgy jó régóta fut élesben, az éles infrastruktúrán, éles pénzekkel az azonnali átutalási rendszer, és az egyes szereplők nézik, hogy az elvárásoknak megfelelően működik-e. Teljes piaci képem nekem is csak annyi van, amennyit az MNB és a GIRO kommunikál erről, aszerint minden rendben van, mindenki jól működik. Úgy legyen :-)
"amennyit az MNB és a GIRO kommunikál erről, aszerint minden rendben van, mindenki jól működik. Úgy legyen" - pontosan. Bő három hét, és kiderül.
Ezek a hatásvadász címek...
Amúgy azzal, hogy a sima utalás is azonnali lesz, a VIBER megszűnik, vagy attól még van létjogosultsága?