Eltűnt a MobilBank app a telefonomról - tud ilyet a Google?

Android

Ma reggel vettem észre, hogy a hajnalban még használt MobilBank app szó szerint eltűnt a telefonomról, nem elérhető a beállítások között sem, a futó alkalmazások között pedig nem nyílik meg. Újraindítás után sem találtam meg. Csak frissíteni lehet a George-ra, ami sajnos még szerverhiba miatt nem működik.

Más is találkozott ezzel? Eddig csak úgy tudtam, "veszélyes" alkalmazásokat töröl távolról a Google, ilyen jellegű frissítés kikényszerítéssel még nem találkoztam.

  • 2598 megtekintés

( _ventura_ v | 2021. 02. 08., h – 08:36 )

Szerkesztve: 2021. 02. 08., h – 08:37

https://hup.hu/node/172598

Egy ideje minden alakalommal mikor beléptem írta, hogy február 8 án ez lesz. 

A régi már nem, az új még nem működik :D Ez van.

Bár nekem most megy, bár kicsit lassan. Kell 1-2 nap mire összeáll szerintem.

Fedora 41, Thinkpad x280

( duffy v | 2021. 02. 08., h – 09:02 )

Works for me. Egyelőre frissítés nélkül simán beléptetett és működik. Nem lassabban, mint korábban...

( yetii | 2021. 02. 08., h – 10:22 )

Szerintem ehhez nem kell a Google, az Erste ha akarja, akkor kitol neked egy frissítést, ami kvázi törli a régit.

marmint indirekt. egy android app nem tudja magat modositani, csak android-on keresztul, az meg rakerdez a user-nel, meg amugy is jog kell hozza.

azt lehet, hogy az app-ben van egy remote kill switch, kvazi, mintha kihuztak volna a remote API -bol a dugaszt.

de eltuntetni nem lehet.

 

Ezen felul persze az app store auto update-t ertelmes ember kikapcsolja, pont ezert. nincs orvul, segged alatt update-elt app.

Olyan nincs, hogy ez a Google Play szerint ugyanaz az app, mint a Mobilbank, csak más neve és ikonja lett?

De igen, pontosan ez a helyzet. A csomagnév maradt pegasus.project.ebh.mobile.android.bundle.mobilebank, az aláíró kulcs is ugyanaz az f5bd861b33e5bf77d47a3ebee44f30d1. A név változott MobilBank-ról George-ra, illetve a launcherben megjelenő aktivitás a korábbi pegasus.project.erstebank.mobile.android.bundle.mobilebank.ui.splash.SplashActivity helyett at.beeone.george.SplashScreenActivity. Nem minden launcher kezeli jól, ha menet közben változnak az indító aktivitások, ilyenkor előfordulhat, hogy a régi ikon még látszik, de nem működik, az új pedig még nem jelenik meg. A launcher (vagy a telefon) újraindítása megoldja ezt a problémát.

Nem tudom, hogy a posztolónak pontosan mi volt a tapasztalata, de az in-app update feature-rel le lehet blokkolni egy alkalmazást szinte teljesen:

https://developer.android.com/guide/playcore/in-app-updates

 

Annyi kell hozzá, hogy az alkalmazás észlelje, hogy egy kritikus frissítés érhető el a play store-ból, és tetiltja magát.

( PDA_FAN | 2021. 02. 08., h – 17:23 )

Nem tudom, mit gondol az Erste a mobil applikációkól, de nekem az első benyomásom negatív az új George (WTF George?) appról... A régi mobilbank nem volt egy vizuális orgia (szerencsére), viszont hamar meg lehetett benne mindent találni. Az új csak kibasz két widgetet a nyitóképernyőre, az egyik ráadásul valami reklámbanner-szerűség, ami az Erste mindenféle okosságát reklámozza. Aztán lehet lapozgatni, görgetni jobbra-balra, hogy valami infót megtalálj. Legalább a számomra fontosabb funkciókat ki lehetne tenni az elejére - de nem lehet, vagy legalábbis nem triviális, hogyan lehetne.

Amikor végre sikerül eljutni a tételes tranzakciókhoz, akkor ugyan ki tudja tenni a Spar meg a Lidl színes logóját (ami tényleg létszükséglet), cserébe a magyar ékezetek egy részével hadilábon áll. Gáz.

Megnéztem. Az enyém egy dashboarddal indul, ami kiteszi egymás alá a számláimat és a hitelkártyámat.

Áttekinthető, sallagmentes. Egy bajom van, hogy nem lehet az engem érdeklő számlákat felülre tenni, így pl. a hitelkártyához scrollozni kell.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( zeller | 2021. 02. 08., h – 21:50 )

A kezdőképernyőre kirakott ikon nálam szürke lett az új verzió telepítése után, de az alkalmazások között ott volt az új verzió, és megy is.

( gelei v | 2021. 02. 09., k – 08:15 )

Ha én MNB lennék, minden banki appnak ki kellene tudni renderelni az összes számla egyedi nevét és aktuális egyenlegét az ikonra kattintás utáni 1 másodpercen (leszámítva, amíg a kódot beírod, vagy Face ID, stb) belül. 

Erre azért vannak egészen objektív mérési módszerek, nyilvánvalóan nem a másfél soros hup kommentemet gondoltam volna Ctrl-C Ctrl-V törvénybe iktatni. :)

Rengeteg olyan projektet láttam, ahol az SLA-ban ilyen kitételek voltak, és mindenhol sikerült közös nevezőre jutni, hogy milyen feltételek között kell garantálni az elérési időt. Annál sokkal nagyobb és sokkal kisebb cégeknél is, mint egy Erste Hungary. Ez gondolom megint ilyen ungarische kereskedelmi banki gyakorlat, hogy nem lehet, jó az úgy. :P

Egy random mobbilos kliensen, aminek a garantált hálózati sávszélessége 0kbit/s. Oké, hogy L7-ben van "azonnali" megoldás, de mire L7-ből L1 lesz, majd átmegy az adat, és L1-ből ismét visszamászik L7-re, annak az ideje kifejezetten nem garantálható, hogy mennyi. Nem, websocket-en sem.

Más iparágakban hogy oldják meg, hogy közel realtime látod ennél komolyabb hálózati forgalom eredményét is? Egy másodperces késleltetéssel már többszereplős videokonferenciát is lehet csinálni, publikus felhővel, gombokért. Hogy van az, hogy egy random magyarországi bank képtelen 10 másodpercen belül kirajzolni egy statikus számot, ami az én esetemben pl. havi max 5 alkalommal változik? :)

Egyébként senki nem beszélt 100%-os SLA-ról. Ha tízből kilencszer sikerül, az már egy baromi nagy előrelépés UX-ben. Valaminek a válaszidejét megmérni sem rakétatudomány, rengeteg projektben van olyan követelmény, hogy X időn belül response-t kell adni, és hidd el, meg lehet csinálni. Mérésekkel, SLA-val, minden bizbasszal. Senki nem mondott olyat, hogy az MNB-nek a puszta közepén kéne mérni az elérési időt, ahol térerő sincs. :)

A "megoldják" és a "kötelezően renderelje a kliens 1s-en belül az aktuális számlaegyenleget" között azért van néhány árnyalatnyi különbség. (mert az eredti felvetés ez volt: 1s-en belül a kliens a felhazsnálói felületen jelenítse meg az egyenleget)
Lehet mérni, tudom - dynatrace jó dolog (ha nem nézed meg, hogyan is működik/épül fel...), szép dolog, de ettől még kötelezően előírt 1s-es időlimitet adni olyanra, aminél a sebességre hatással lévő komponensek egy igen nagy szeletére nincs hatása a banknak, nos... Bár láttunk már a törvényalkotótól fasságot máskor is, ez igaz :-P

ettől még kötelezően előírt 1s-es időlimitet adni olyanra, aminél a sebességre hatással lévő komponensek egy igen nagy szeletére nincs hatása a banknak, nos... 

Akkor máshogy fogalmazom. Meg lehet mérni valamit úgy is, hogy nem stopperrel méred, ahogy a mobilodat nyomkodod. Akár úgy is, hogy a komponenseket külön méred. Értelemszerűen az 1 sec limit arra vonatkozna, amire a banknak van ráhatása. Ha nem jön össze az 1s, mert basztad kifizetni a telekomnak a mobilnetet, és ezért belassított, azt nem számolnám bele. Ha az óceán közepén vagy, és húszezer forintonként pörgeted a megabájtokat maritime APN-en keresztül, azt sem számítanám bele. Tényleg nem érted, vagy csak próbálod úgy csavarni a dolgot, hogy lehetetlennek tűnjön egy olyan dolog, amit a bankvilágon kívül már kb. mindenki megoldott?

Ne próbáld már bemagyarázni plz, hogy azért tart 10+ másodpercig megjeleníteni az egyenlegem, mert lassú a wifi otthon, vagy szar a mobilom, vagy mittudomén, de a banknak biztosan nincs semmi ráhatása. Légyszi, ezt az egyet azért ne. :)

Ismétlem (utoljára, utána elengedtem a témát, mert úgy érzem, nem fogok tudni újat mondani): a javaslatom nem arról szólt, hogy a földön mindenhol, minden eszközzel 1s legyen kattintástól kattintásig, hanem hogy a tetves banki API ne 10 másodpercig keresgélje az egyenlegem. Úgy gondolom 2021-ben, amikor már önvezető autók vannak az utakon, géppel műtenek betegeken neten keresztül, tízezer ember hallgat egy előadást pár másodperc késéssel, ez nem egy lehetetlen gondolat.

szerk: és most nem olyan problémákról beszélünk, hogy a 24 óránként futó batch 25 órán keresztül fut az AS400-on, hanem hogy egy HTTP GET kérés 1 másodpercen belül visszaadjon egy <1 KB-s json-t.

Láttam olyat, aki hallott olyanról, akinek voltak kifejezetten end-to-end mérési adatai (dynatrace), és bizony a lassulásokban mobilos végpontok esetében döntően a mobilhálózat, illetve az üf.-nél lévő mobilos böngésző volt a ludas.

" a javaslatom nem arról szólt, hogy a földön mindenhol, minden eszközzel 1s legyen kattintástól kattintásig, hanem hogy a tetves banki API ne 10 másodpercig keresgélje az egyenlegem. "

A javaslatod egészen pontosan ez volt:

"Ha én MNB lennék, minden banki appnak ki kellene tudni renderelni az összes számla egyedi nevét és aktuális egyenlegét az ikonra kattintás utáni 1 másodpercen (leszámítva, amíg a kódot beírod, vagy Face ID, stb) belül"

Ha a banki API pártíz ms-en belül válaszol, és visszaadja az adatot, de a telefonod rottyon van, és nem igazán gyors, elelnben lassú procival van megverve, akkor mi van? És mi van akkor, ha van mondjuk 5 vagy 10 számlád? Akkor van 100-200ms/darabnyi idő adatot lekérdezni, a visszakapott adatokat átpasszolni a megjelenítő rétegnek, és a képernyőre kirakni azokat. (5 számla pillantok alatt összejön: folyószámla, moratórium számla, hitelkártya, gyerekek számlája (rendelkezési jog van rajta, ezért látom), megtakarítások, és máris sokasodnak a megjelenítendő adatok (az "egyenleg" mellé oda köll tenni a zárolásokat is...)
 

és bizony a lassulásokban mobilos végpontok esetében döntően a mobilhálózat, illetve az üf.-nél lévő mobilos böngésző volt a ludas.

Ne már. Akkor hogy van az, hogy a brokercégem appja login után kb 1-2 másodperccel már realtime portfólió adatokat mutat, de a 2-3 magyar kereskedelmi banki app meg teker vagy 5-15 másodpercig, mire kijön 1 db statikus szám?

Ha a banki API pártíz ms-en belül válaszol, és visszaadja az adatot, de a telefonod rottyon van, és nem igazán gyors, elelnben lassú procival van megverve, akkor mi van?

Akkor azt nem mérjük. Direkt leírtam, hogy nem Ctrl-C Ctrl-V kellene jogszabályba illeszteni a kommentemet, hanem végiggondolni, hogy mit és hogyan lehet szabályozni. Ne haragudj, de az, hogy ez lehetetlen feladat lenne, az bullshit. Ezt onnan tudom, hogy van több (külföldi) bankkal, brokerrel, stb. kapcsolatom, akiknek sikerült.

És mi van akkor, ha van mondjuk 5 vagy 10 számlád?

Ha szőrszálakat hasogatunk, akkor legyen 1+(0.5*$countSzámlák) másodperc a limit, de baromira nem ez a lényeg. :)

A gond továbbra is azzal van, hogy ennél jóval komplexebb problémákat más iparágban simán megoldanak, de még ebben is, ha elindulsz nyugat felé.

Ha a banki API pártíz ms-en belül válaszol, és visszaadja az adatot, de a telefonod rottyon van, és nem igazán gyors

A telefonom tetszőleges (gyors) weblapot másodpercek alatt megjelenít. Bizonyos sport stream app 2-3 másodpercen belül betölt, rányomok a meccre, 5 másodpercen belül a stream-et nézem. Youtube app másodpercek alatt elindul, egy videóra nyomva kb. instant kezdi lejátszani (tizedmásodperc nagyságrend lehet a delay). Ezt tudják az otthoni neten, a céges neten, haverok/család/stb. helyeken, illetve mobilneten is, legalábbis 100-ból 95 esetben simán megy.

Az erste korábbi netbankjánál, illetve ennél a dzsordzs nevű csodánál többször is előfordult az, hogy indításkor az ujjlenyomat beolvasása után annyit homokórázott, hogy a 30 másodpercre beállított screenlock előbb bekapcsolt, mint hogy ez a csoda behozza a kezdőképernyőt az oda tartozó adatokkal. Most mértem egyet ezzel a retekkel, 3 másodperc kellett neki, hogy bekérje az ujjlenyomatomat. Majd miután ez sikerült, mindössze 16 másodperc után már meg is mutatta a 2 (kettő) darab számlámat, az egyenleggel és az elérhető összeggel.

3-5s az elindulás és a biometrikus azonosítás, utána 13-16s alatt dobja fel négy számla egyenlegét. Lehetne gyorsabb, ez igaz (másik mobilbanki app az utolsó tranzakciók listájával együtt bármikor 10s-on belül felhozza az egy szál számlám egyenlegét - igaz, ott nincs cloud, nincs PFM, meg egyéb kényelmi "ingyombingyom" - és garantáltan magyarországi vasakon fut csak), de ez pont az a válaszidő, amit még el lehet fogadni.
 

igaz, ott nincs cloud, nincs PFM, meg egyéb kényelmi "ingyombingyom"

Ezek közül melyik kell az egyenleg megjelenítéséhez? Nem lehet a háttérben tökölni PFM-mel?

10s-on belül felhozza [...] ez pont az a válaszidő, amit még el lehet fogadni.

10 másodperc az borzasztóan sok, pláne mobilon.

A legfeljebb 10s ott az app indulása, biometrikus azonosítás és kezdőoldal betöltés egyben akkor, ha épp sz@r a mobilnet :)
 

Nekem Erste esetében az a gyanúm, hogy "messze van" a mobilbanki frontend a számlavezető rendszertől, és az egyenleg lekérdezés sok olyan lépésből áll, amit bőven ki lehetne, illetve ki kellene optimalizálni a rendszerből. De ez csak egy tipp, semmi több.

13-16s alatt dobja fel ... Lehetne gyorsabb, ez igaz ... , de ez pont az a válaszidő, amit még el lehet fogadni.

El lehet fogadni, persze. Azért, mert olyan sok választásod van ám. Ha nem fogadod el, akkor mégis mit csinálsz? Másik netbank appot használsz? xD Az egyedüli lehetőség az, hogy bankot váltasz, én ezután a dzsordzos faszkodás után ezen komolyabban el is fogok gondolkodni, pedig csak huszonéve vagyok náluk.

Nagy szar ez az egész, 16 másodperc, come on, egy perc negyede elmegy a semmire. Mert nem képesek normális rendszert összetákolni, hanem jó ez _szerintük_ nekem. Mert én annyira ráérek, ugye.

Egy utalásnak országon belül _5_ másodpercen belül _kell_ teljesülnie, azt hiszem ezzel nem mondok nagy újdonságot. Mindezt úgy, hogy a saját számlaegyenleg ellenőrzése után egy másik bankkal kell kommunikálni, ahol nyilván megtörténik a számla létezésének az ellenőrzése és a pénz jóváírása, illetve a hatósági levonások és hasonlók ellenőrzése is, meg még egy csomó dolog, amire nyilván nem is gondolok. Aztán meg a visszajelzés, hogy a tranzakció sikeres-e, vagy nem.

Na ehhez képest a _saját_ számláim és azok egyenlegének a megjelenítésére az elfogadható szintidő 1 másodperc, annál semmiképp se több.

"Nagy szar ez az egész, 16 másodperc, come on, egy perc negyede elmegy a semmire. Mert nem képesek normális rendszert összetákolni," - szerintem jelentkezz chief architect pozícióra, és mutasd meg, hogy kell...

Az IG3 működését kifejezetten leegyzserűsítetted, ez az egyik. A másik, hogy ott azért a résztvevők (mind a hárman) kifejezetten magas rendelkezésre állású, dedikált eszközöket és hálózati útvonalakat használnak az adatcserére.

"Na ehhez képest a _saját_ számláim és azok egyenlegének a megjelenítésére az elfogadható szintidő 1 másodperc, annál semmiképp se több." - Ismét a kérdés: hány számla esetén? mert nekem per pillanat négy számlát jelenít meg, melyek között van folyószámla, hitelkártya (másik rendszer), moratórium számla (nullás, de azt is meg kell mutatni) - és még lesz mellé pár termék, ha úgy alakul.
 

Ismét a kérdés: hány számla esetén? mert nekem per pillanat négy számlát jelenít me

Tudod mit? Legyünk nagyvonalúak! Legyen számlánként 1+1*$countSzamla másodperc a limit, négy számlánál még az is a "pont elfogadható" 10 másodperc fele. :)

nekem per pillanat négy számlát jelenít meg, melyek között van folyószámla, hitelkártya (másik rendszer), moratórium számla (nullás, de azt is meg kell mutatni) - és még lesz mellé pár termék, ha úgy alakul

Úgy gondolom, hogy értelmesen is hozzá lehet állni a feladathoz, pl. limitálni az instant kiírandó számlák darabszámát, mint ahogy azt néhány másik bank csinálja. Ha a nullás technikai számla ugyanúgy 10-30 másodperc marad, az kit nérdekel, azzal együtt lehet élni.

Egyébként a legelborultabb lakossági ügyfélnél is nagyon maximum átlagban napi tízszer ha megváltozik az egyenleg, de szerintem sokat mondtam. Minek ehhez elmenni a számlavezető rendszerhez?

"Egyébként a legelborultabb lakossági ügyfélnél is nagyon maximum átlagban napi tízszer ha megváltozik az egyenleg, de szerintem sokat mondtam. Minek ehhez elmenni a számlavezető rendszerhez?" - mert mondjuk nem a reggeli/1 órával/x perccel ezelőtti egyenleget _kell_ megmutatni?

mert mondjuk nem a reggeli/1 órával/x perccel ezelőtti egyenleget _kell_ megmutatni?

Bár lenne valami megoldás arra, hogy egy ritkán változó, statikus adatot eltároljunk valami gyors elérésű helyre, hogy ne kelljen mindig a core rendszerben kapálózni érte, és ha mondjuk megváltozna, akkor felül lehetne írni az új értékkel. :)

Nomostan az "egyenleg" az lehet könyvelt egyenleg, meg elérhető egyenleg, azaz rögtön minimum két értéket kell legalább két helyen kis késleltetéssel szinkronban tartani. Ezt vagy úgy csinálják, hogy egy helyen tárolják, és aminek/akinek kell, az "odamegy" érte (net/mobilbank esetén nem biztos, hogy jó ötlet), vagy a netbank/mobilbank is tárolja az értékeket, amit vagy akkor frissít be, amikor az üf. explicit rákérdez, hogy "mennyi" (bejelentkezik az alkalmazásba/netbankba), vagy pedig a számlavezető rendszer "push"-olja felé a változást, miután a változást generáló tranzakció megfelelő állapotát beállította (pl. bejött egy kártyás vásárlásról egy zárolás, akkor az elérhető egyenleg csökken, a könyvelt majd csak akkor, ha a zárolt összeg terhelése is megtörténik.)
 

Az átlag usert elsősorban az érdekli, hogy hány forintja van még, amit elkölthet, mielőtt jönne a következő fizu. Szerintem szinte senki nem foglalkozik vele, hogy a hitelkártya tranzakciók mikor könyvelődnek le, de ha mégis, az majd kivárja szépen a 10-30 másodpercet a részletes nézet betöltésekor. :)

Hááát... ha valaki azt nézi, hogy egy hitelkártyával mennyit tud még elkölteni ahelyett, hogy mennyit költött el eddig, az szeret veszélyesen élni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

OK, akkor hitelkártyánál 2*32 bitet kell cache-elni, de miért érdekes ez? :) Ettől még a mindennapokban, az átlagos usernek nem érdekes infó, hogy egy hitelkártya-tranzakció zárolt, vagy könyvelt - emiatt én nem bonyolítanám a splash screenen megjelenített egyenlegeket, ha az a cél, hogy gyorsan hozzáférhető legyen.

Nomégegyszer... Mikori, mennyivel korábbi adatot cache-eljen a netbank/mobilbank? És mi triggerelje az eltárolt adat frissítését?  Van oylan, ahol a számlavezető rendszer "push"-olja a netbank/mobilbank felé az összes, ott megjelenítendő változást, és van, ahol meg a netbank/mobilbank küld egy kérést a számlavezető rsz. felé, hogy mondja meg, mennyi a könyvelt/zárolt/satöbbi összeg az adott ügyfél adott számlájánál. Aztán amikor jön válasz, akkor tudja megjeleníteni. Totál mindegy, hogy az adat mennyi, a kérés/válasz ideje, illetve időpontja/trigger, ami kiváltja azt az a releváns.

"az átlagos usernek nem érdekes infó, hogy egy hitelkártya-tranzakció zárolt, vagy könyvelt" - nagyon nem mindegy a kettő, és tippre az MNB keményen ráharapna, ha csak az egyiket, illetve "valami korábbi állapot"-ot jeneítene meg a felület.

Van oylan, ahol a számlavezető rendszer "push"-olja a netbank/mobilbank felé az összes, ott megjelenítendő változást

A push elég megbízhatatlan mobilon, én nem a mobilappra támaszkodnék, mint cache.

és van, ahol meg a netbank/mobilbank küld egy kérést a számlavezető rsz. felé, hogy mondja meg, mennyi a könyvelt/zárolt/satöbbi összeg az adott ügyfél adott számlájánál

Én ezt piszkálnám inkább meg. Az egyenleg gyors rendereléséhez mi szükség van egy ilyen felbontásra? Az ID+egyenleg párost kell kivezetni valami gyorsan elérhető API endpointra, az emögött álló adatbázist pedig etetném a számlavezető rendszerből. A "mennyi a zárolt összeg" ráér, ezeket a háttérben be lehet húzni, nem kell hozzá a UI-t blokkolni. Ha a user erre kíváncsi, akkor úgyis ki fogja várni. Nézd meg mondjuk, hogy működik a Revolut app user szemszögből. 

Nem véletlenül írtam úgy, hogy "push"-olja. A számlavezetőben történik egy esemény, és a számlavezető rendszer "szól ki" a net/mobilbanknak (jellemzően queue-n keresztül), hogy az x számla kapcsán y változás történt.

"Az egyenleg gyors rendereléséhez mi szükség van egy ilyen felbontásra?" - Melyik egyenleg? (elérhető? könyvelt?) - ez az egyik. A másik, ami szintén megfontolandó, hogy egy kéréssel mit és mennyi információt (és mennyi idő alatt) kap meg a kliens. Sokszor célszerűbb egy kérés-válasz párossal több információt is odatolni a kliensre, nem minden értékre külön "megfutni a köröket".

"Az ID+egyenleg párost kell kivezetni valami gyorsan elérhető API endpointra, az emögött álló adatbázist pedig etetném a számlavezető rendszerből. " - igen, ez a másik lehetőség, amikor a számlavezető rendszerből a netbank/mobilbank számára fontos adatokat az előbbi mondjuk egy queue-n keresztül vagy máshogy tolja ki a netbank/mobilbank alá, és a klienseket kiszolgáló webes alkalmazásszerver onnan szedi öassze, ami kell.

Szerinted a "mennyi a zárolt összeg" ráér - mint írtam, az MNB szerint meg nem biztos - a revolut ilyen szempontból irreleváns, egyelőre maradjunk a hazai szabályozásnak való megfelelés területén.

 Melyik egyenleg? (elérhető? könyvelt?)

Továbbra is az elérhető :)

Szerinted a "mennyi a zárolt összeg" ráér - mint írtam, az MNB szerint meg nem biztos

Na, álljunk meg egy picit, én nem azt mondtam, hogy a többit ne írjuk ki. Azt mondtam, hogy az egyenleg renderelhető gyorsan, és utána, a háttérben (már splash screen nélkül) be lehet húzni a többi infót. Egyébként ez biztosan MNB-compliant, az OTP app még login előtt is meg tudja mutatni az elérhető egyenleget. Ha az nem elég, akkor login, még több várakozás, és ott a többi.

"Na, álljunk meg egy picit, én nem azt mondtam, hogy a többit ne írjuk ki. Azt mondtam, hogy az egyenleg renderelhető gyorsan" - Azt is le kell húzni a netbank/mobilbank mögötti valamelyik DB-ből, és ha már bemegy egy kérés, akkor lehetőleg minél több információt toljunk ki egyszerre a kliensre. (Ha csak egy elérhető egyenleget húzna le a kliens (melyik számla?), a többit meg "majd a háttérben", akkro rögtön minimum duplázódna a kérések száma a kliens és a mobilbanki kiszolgál között. És ne felejtsd el, hogy nem egy PoC néhány useres demóról, hanem jelentős ügyfélkört kiszolgáló rendszerről van szó, ahol még pár %-nyi megspórolt erőforrás költsége is szép summa.

És ne felejtsd el, hogy nem egy PoC néhány useres demóról, hanem jelentős ügyfélkört kiszolgáló rendszerről van szó, ahol még pár %-nyi megspórolt erőforrás költsége is szép summa.

Akkor ezert tettek ala egy 2-es Raspberry Pi-t. Legalabbis erzesre annak tunik.

A strange game. The only winning move is not to play. How about a nice game of chess?

Hmm. Revolut fórumok tanúsága szerint vannak időszakok - nem is ritkán - amikor a Revolut app esik/kel. Ha "tetszőleges" bank így viselkedne és ilyen sűrűn, akkor szerintem már az MNB-t ostromolnák a dühös ügyfelek (nem csak a mobilapp, de kártyás tranzakciók is elhalnak ilyenkor). De persze 'legalább ingyen van'... Mellesleg egyre kevésb van ingyen, most is bejelentettek némi plusz korlátozást.

Nem a Revolutot dicsérem úgy általában, hanem azt, hogy képesek olyan csúcstechnológiai bravúrokra, mint egy statikus integer lekérdezése API-n, gyorsan. :) Értem amúgy az issue-kat, én sem vagyok különösebben rajongójuk.

Nem muszáj amúgy a Revoluton lovagolni, az IBKR app a FaceID azonosítás után 1-2 másodperccel mutatja az egyenleget (amiben FX váltás is van), a legnagyobb pozícióimat realtime árfolyamokkal, és a watchlist-em papírjait realtime árfolyamokkal. Ehhez képest a magyar bankoknál egy HUF folyószámla egyenleg kijelzése 10-20-másodperc. 

No, akkor fussunk neki... Van a mobil appod, az elindul, biometriával előkotorja a bejelentkezési adatokat, elmegy a mobilbank/netbank kiszolgálását végző webszerverhez, az redirect oda-vissza egy IDM-hez, majd amikor ez megvan ("visszajött" az IDm-tő, megfelelő sütikkel, credential-lal, egyebekkel, akkor ez alapján a netbank/mobilbank elmegy queue-n keresztül, vagy épp a saját DB-hez, összeszedi, milyen számlái vannak az adott üf.-nek, összeszedi mindenek a tranzakciós listáját, egyenlegét, az üf.-nek szóló üzenetek számát, miegyebet, és visszaadja a kliensnek, amit az ezt követően elkezd renderelni. A "miért mindent is egyben" oka egyszerű: egy kérés/válasz elég, nem 10-20 vagy több kérés/válasz párossal operál a motyó. Hogy miért? Nem mindegy, hogy x vagy 10*x kérés kiszolgálására kell méretezni a szervereket.

Nem mindegy, hogy x vagy 10*x kérés kiszolgálására kell méretezni a szervereket.

Már többedszerre javasoltam, hogy nem mindent egyesével kell lekérdezni, hanem kell két bucket

  1. adatok, amik azonnal kellenek (pl. egyenleg)
  2. adatok, amik kivárhatják a mostan is létező 10+ másodpercet (pl. utolsó X tranzakció adatai)

Az 1-es bucket egy kérés, a 2-es bucket még egy kérés, a háttérben. Ezzel az egyetlen változtatással (a komplexebb query-k nem blokkolják a UI-t) az app máris sokkal reszponzívebbnek tűnik, és a user kevésbé fog anyázni.

Milyen távolról láttál banki it-rendszereket?

Elég közelről. Retail és IB vonalon is. Még a regulatory oldal sem teljesen ismeretlen. Ha azt szeretnéd hallani, hogy rengeteg banknál az IT tele van TD-vel, és ezért baromi nehéz fejleszteni bármi értelmeset, akkor igazad van, szerintem sok banki rendszernek lenne a szemétdombon a helye.

Az "egy változtatás" ötletedről nekem ez jut eszembe

Mert? Ennél jóval bonyolultabb problémákat is láttam már megoldódni elfogadható idő és költségek mellett. Továbbra is arról beszélünk, hogy 1-3 db integert ki kell írni egy mobilalkalmazásban, UI blocking nélkül. Borzasztóan nehéz feladatnak tűnik :P

"szerintem sok banki rendszernek lenne a szemétdombon a helye." - ebben egyetértünk - sajnos példákat nem mondhatok, de elég csak arra gondolni, hogy hány meg hány alkalmazás működik vastagklienssel...

A "ki kell írni"-hez: Mikori (milyen régi) adat az elfogadható, az hol legyen tárolva, hogyan frissüljön - illetve hogy pontosan mit értünk "kiírandó egyenleg" alatt? Van, akinek a felhasználható a lényeges, van akinek a könyvelt - oké, akkor számlánként két értéket kell kvázi folyamatosan (legfeljebb a "milyen régi felel meg" időközönként) frissen tartani (gyakorlatilag valamennyi tranzakciót követően a net/mobilbanki "árnyék" rendszerben is frissíteni) Miközben ha az user elkattint majd vissza, akkor már az aktuálisat kell mutatni, ami lehet, hogy eltér - amiből jön az üf.panasz, hogy "login után 123 petákos egyenleget írt ki, de a részletesben már 115-öt - ha nem tudják mennyi pénzem van, akkor megyek innen" - és üf. szemmel jogosan küldi el az egész bankot melegebb éghajlatra, hiszen a mobilos app két nézete inkonzisztens adatokat mutat.
Van, ahol úgy csinálják, hogy minden tranzakció után a netbank/mobilbank által nyilvántartott egyenleg is frissül, és van, ahol meg nem, hanem a login triggerel egy adatfrissítést, és a friss adatokat jeleníti meg, vagy épp direktben benyúl valamilyen köztes rétegen át a számlavezető rendszerekbe, és előkotorja az üf. egyenlegeit, mondjuk úgy, hogy röptében. Hogy ez a "röptében" egy töröt szárnyú betonbagoly vagy épp egy vándorsólyom, az más kérdés.

Miért futjuk ugyanazokat a köröket újra és újra? :)

Van, akinek a felhasználható a lényeges, van akinek a könyvelt

Szerinted az emberek hány százaléka tudja, hogy mi a különbség? Tízből kilenc retail ügyfelet szerintem az érdekel, hogy mennyi pénze van, amit el tud elkölteni, de tartok tőle, hogy keveset mondtam. Ha érdekli, hogy ebből mennyi a zárolt, és mennyi a könyvelt, akkor majd kivárja a 10+ másodpercet, ahogy eddig. Rosszabb nem lett neki. A 90+ százaléknak viszont jobb lett a UX.

Van olyan app itt a telefonomon, ami meg tudja ezt csinálni. Nem kell túlmisztifikálni a feladatot, valahol már megoldották, és működik.

Nekem is van olyan moboilbanki app a telefonomon, ami jóval gyorsabb, mint Gyuri, igaz, funkcionalitását tekintve - nem utolsó sorban a bank által kínált pénzügyi termékek jóval szűkebb köre miatt - jóval egyszerűbb, és mivel nem az az elsődleges számlám, így a PFM funkcionalitást nem hiányolom belőle.

szerintem jelentkezz chief architect pozícióra, és mutasd meg, hogy kell...

És ha elégedetlen vagyok a közbiztonsággal, akkor jelentkezzek rendőrkapitánynak, ha meg a kormánnyal, akkor pedig miniszterelnöknek, nem? Szerintem nem kicsit szánalmas ez a reakció.

Nyilván nem előírás az, hogy picsalassú legyen, szóval hagyjuk már a szabályokat és előírásokat. A többi meg bullshit, már ne haragudj. Azt tudom, hogy ez szar. Nem tudom, hogy azért szar-e, mert karcsú alatta a vas, vagy azért, mert szarul van megírva, esetleg a kettő együtt. És ez nyilván nem azt jelenti, hogy én jobban meg tudnám csinálni, de az azért sokat mond, hogy 1 nap alatt sikerült 1,6 pontra lemennie a store-ban 2,1 pontról. Szóval nem volt magasan a léc, de legalább azt se sikerült megugrani. Azóta amúgy már 1,7 pont, gondolom kiadták a dolgozóknak hogy fel kell pontozni...

"hagyjuk már a szabályokat és előírásokat." - Ne, ne hagyjuk. Van egy meglévő környezet, számlavezető rendszerrel, IG3-mal, meg 1024 egyéb k1f...ommal, amire nem is gondolsz - ebbe kell beledrótozni egy felhős mobilbankos alkalmazásszerver-halmazt úgy, hogy az alapvető funkciók ne sérüljenek, és az MNB se köthessen bele semmilyen szempontból - ugyanis igencsak szeretik drágán mérni a "belekötéseket".

"gondolom kiadták a dolgozóknak hogy fel kell pontozni" - Tipikus magyarosch rosszindulat - nem vagyok Erste-s dolgozó, csak ügyfél, és bizony én is toltam rá a régi mobilbank értékeléséhez képest egy jobb "jegyet" - ugyanis többet tud, _nekem_ nagyjából az első 2-3 használat után legalább annyira kényelmes, mint az előző volt - a plusz tudás miatt meg pláne megérdemli a jobb minősítést (sebességre a régi sem volt gyorsabb egyébként...)

Revolut: 4 sec

George: 20 sec

Ennek egyik oka, hogy a Revolut fülekre bontja az elérhető termékeket, így az app indításánál csak a folyószámla egyenlegét tölti be, míg az Erste az összes elérhető számlát.

Kriptodeviza esetén ennél is cselesebb: az utolsó letárolt értékkel azonnal indul, majd a frissítés után átpörgeti a számokat. 

Nyugi, láttam már közelről netbank/mobilbankot - a "másik oldalról" is :-)  Nem azt írtam, hogy nem lehetne gyorsabb, hanem azt, hogy a meglévő infrastruktúrához és folyamatokhoz kellett igazítani, és az bizony hordozhat magában korlátokat, problémákat - amiket vélhetőleg ki fognak kalapálni - bár a korábbi válaszideje sem volt sokkal kevesebb - sőt. Csak ott beraktak egy képernyőt ("mindjárt készen vagyunk, de tényleg", vagy mi a szösz), ami picit (hangyabokányival) jobb, mint a "nem történik semmi".

Azt tartom problémásnak, hogy itt 10-ből 9 (és fél) megszólaló csak a frontendet nézi, és totálisan ignorálja azt, hogy ennek egy igen összetett konglomerátum részeként kell működni, amiben való igaz, vannak legacy sz@rkupacok, meg olyan módszerek/folyamatok, amiket már sok évvel ezelőtt sem így kellett volna csinálni. Viszonz banki/pénzintézeti környezetről van szó, ahol nagyon igaz az, hogy "ami működik, és nem b...ogat érte az MNB, aut nem piszkáljuk".
 

Azt tartom problémásnak, hogy itt 10-ből 9 (és fél) megszólaló csak a frontendet nézi, és totálisan ignorálja azt, hogy ennek egy igen összetett konglomerátum részeként kell működni

Nem problémás, csak épp a 10-ből 9,5 elégedetlen ügyfél megszünteti a számláját és máshová viszi a pénzét. Azokhoz a másik bankokhoz, amik gyors és intuitív felületet adnak nekik.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

gyorsabb, divatosan mondva reszponzívabb

Ugye ez csak vicc volt és valójában tudod, hogy a reszponzív az nem a sebességgel van összefüggésben?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Van egy meglévő környezet, számlavezető rendszerrel, IG3-mal, meg 1024 egyéb k1f...ommal, amire nem is gondolsz - ebbe kell beledrótozni egy felhős mobilbankos alkalmazásszerver-halmazt úgy, hogy az alapvető funkciók ne sérüljenek, és az MNB se köthessen bele semmilyen szempontból

A számlavezető rendszert pár éve cserélték, volt is emiatt egy komolyabb leállás, ekkor ment a levesbe a régi, jól használható netbankjuk is. Szóval elvileg szép, új, csodás rendszerük van. És értem én, hogy bonyolult meg minden, de ha pár másodperc alatt _lezajlik_ egy átutalási vagy egy kártyás fizetési tranzakció (ami egyrészt tartalmaz számlaegyenleg lekérdezést is, másrészt pedig sokkal több is annál), akkor ne kelljen már 20 másodpercet várni egy mobilbank app kezdőképernyőjének a betöltésére.

Tipikus magyarosch rosszindulat

Tipikus magyarosch hozzáállás az, hogy ha valami sz*rt csináltunk, akkor kiadjuk a dolgozóknak, hogy pontozzák fel, hogy legalább ne látszon az, hogy annyira sz*r.

bizony én is toltam rá a régi mobilbank értékeléséhez képest egy jobb "jegyet" - ugyanis többet tud

Ez azért komolyan érdekelne, hogy mivel tud többet, mint a korábbi.

"ekkor ment a levesbe a régi, jól használható netbankjuk is" - csak a felület lett lecserélve, ha jól tudom.

Az IG3 meg a kártyás tranzakciókra kifejezetten kötött időlimitek vannak, ez az egyik, a másik, hogy ezek a tranzakciók "direktben" a rendszer mélyebb "rétegeibe" esnek be, amikhez a net/mobilban csak több lépcsőn/queue-n/egyeben keresztül férhet hozzá. Bónuszként az IG3 vagy épp a kátyás tranzakciónál a tranzakciós adatok mozognak, egy mobilbanki kliens és a kiszolgáló között meg a felületet leíró tartalom egy része is.

"mivel tud többet, mint a korábbi." - Vizuálisan nekem átláthatóbb/szebb, de ez kifejezetten szubjektív, tudom. Amiben mindenképp többet tud, az például a PFM funkcionalitás (amiből tippre még messze nincs minden bekapcsolva), vagy épp a "termékek" oldal, ahol példul a befektetéseket lehet elérni/csatolni a meglévő számlák mellé. Szerintem ide több banki/pénzügyi/biztosítási termék illetve szolgáltatás is be fog kerülni majd idóvel.

 

csak a felület lett lecserélve, ha jól tudom

Hát tudja a fene. Az új netbank csodái:

- lassabb

- a tranzakciókat a könyvelés dátuma szerint rendezi

- a korábbi 15 perc helyett 3 percig használható új lap/fukció/akármi töltése nélkül. (Ezt 5 percnek hazudja, de 3 perc múlva felugrik egy ablakocska amin ha azt nyomod, h szeretnél belépve maradni, akkor _újratölti_ az épp aktuális oldalt.)

panaszkodók + elégedettek < teljes ügyfélkör

Az emberek nagy része csak csendben anyázik egyet. Amúgy a 10-30 másodperces banki loading screenekre eddig csak banki alkalmazott mondta az ismerősi körömben, hogy jól van az úgy, szóval ez a százalék lehet elég magas is. :)

Lassú: loading screeneket látok, miközben nem super PI-t számolok végtelenig. Tessék megírni úgy hogy <0.1s legyen a válaszidő bármilyen requestre. Sajnálom. Nem érdekelnek a kifogások, meg hogy minden bonyolult. Tárolják megfelelően az adatokat és ne 21313 mikroszervizből kelljen Thread.sleep-ekkel teletömött legacy rendszerekből összegereblyézni.

Mondom ezt úgy, hogy 10 éve banki kakit túrok.

"Mondom ezt úgy, hogy 10 éve banki kakit túrok." - Gondolom, nálatok ez akkor meg van oldva, qrvagyors a netbankotok/mobilbankotok, és mindenben megfelel az MNB előírásainak is - szerintem jelentkezz az Erste fejlesztői csapatába atyaistenszakértőnek, hogy megmutasd, hogyan kell - ha már a sok hülye nem tudja...

Az előző verzió "mindjárt készen vagyunk - de tényleg" bullshit-jéhez képest nem lett lassabb.

De gyorsabb se, az a baj. Illetve van némi funkcióvesztés is, pl. tudok 24 órára kártyalimitet állítani, mert valaki úgy gondolota, hogy ennyi választás elég lesz nekem. A régivel lehetett 1, 12, 24 és 48 órára állítani, a netbank pedig tud 24 és 48 órát. Bravó.

Most a belépés ujjlenyomat után 7 sec volt, de beléptem az egyik számla zárolásai közé, mejd nyomtam egy vissza gombot (a könyvelt tételekhez), azóta homokórázik. Csak 3x kapcsolt be azóta a fél percre állított screenlock, most volt a 4. Szóval 2 perce nem tud visszalépni arra az oldalra, amit egy "kattintással" korábban mutatott. Azóta megvolt az 5. is, szóval kilőttem az appot, elindítottam, autentikáltam, akkor meg bejött.

Halkan jelzem, hogy dzsordzs élesítésének napján kaptam egy emailt (du. 3 körül, de ez mindegy is) az erste-től, amiben ezt írták: "A kártyalimit-módosítás egyszerűbb: 24 órára tudsz összeget módosítani, aztán visszaállítom az eredetire."

Szóval legyen igazad, de én ebből azt veszem le, hogy ez nem bug, hanem feature...

Lehet - csak tippeltem. Minthogy elég alaposan vizslatják, hogy melyik funkciót/beállítást mennyire használták/használják, így az is lehet, hogy a 24 óra volt kimagaslóan a legtöbb, a többi beállítás meg csak egyszámjegyű százalékban - ekkor érthető, hogy a felület és a belső működés egyszerűsítése okán csak ez az opció maradt.

""A kártyalimit-módosítás egyszerűbb: 24 órára tudsz összeget módosítani, aztán visszaállítom az eredetire." - ezt úgy is lehet olvasni, hogy egyszerűen limitmódosítás - mennyi legyen, és kész, az időt nem kell beállítani - egy lépéssel/paraméterrel kevesebb, egyszerűbb a felület/folyamat.

melyik funkciót/beállítást mennyire használták/használják, így az is lehet, hogy a 24 óra volt kimagaslóan a legtöbb, a többi beállítás meg csak egyszámjegyű százalékban - ekkor érthető, hogy a felület és a belső működés egyszerűsítése okán csak ez az opció maradt

Megmagyarázni én is meg tudom, de ez akkor is fasság.

A régi rendszerrel működött pár intervallum, asszem 4, de nem is ez a lényeg. Ha tippelnem kell, akkor ez kb. úgy működik, hogy bejegyzi valahova, hogy X kártyával Y típusú tranzakcióból Z összeg és n db. engedélyezett, és ide van még csapva az ideiglenes tranzakció lejárati ideje is. Mégis mennyit egyszerűsít az, hogy fix 24h időt jegyez be? Kispóroltak a dzsordzsiból 4 nyomorult gombot, mert a többi része már nyilván kész van. Hát bravó, tényleg

Amúgy minek egyszerűsíteni? Simán indokolt lehetne a korábbiaktól (1-48h) ezektől akár rövidebb, akár hosszabb intervallum is. Pláne úgy hogy ennek leginkább a netes kártyánál van értelme, amit ugye "veszélyes" helyeken használok, azaz nem POS/ATM. Még az 1 óra is túl sok egy ebay vásárlásra, a 24 meg aztán főleg.

"Még az 1 óra is túl sok egy ebay vásárlásra, a 24 meg aztán főleg." - Megkaptam a választ, mondjuk úgy, hogy "nem vagyok elégedett" vele - idézem: "Tájékoztatjuk, hogy a korábbiaktól eltérően a George App keretein belül, időtartam limit, valamint tranzakció db szám maximalizálás beállítása nem megoldható, a kártyához kapcoslódóan csak időzáras (24 órás), és összeg alapú limit beállítására van lehetőség, melyre vonatkozóan szíves megértését kérjük." - Hát b+ Ödön, vagy Gyuri, vagy hogy a pékbe' hívnak, nem értem meg! (Meg is kapták a választ, illendően kulturált formában...)

 

Nem a banki oldal a lényeges, ott jellemzően ott van az up-to-date egyenleg a netbankban, az user oldali eszköz és a banki infra közötti kapcsolat is "bele lesz mérve" a felvetett 1s-os limitbe, miközben ezekre, ezeknek a teljesítményére, sebességére nincs a banknak ráhatása.

Semmilyen publikus dokumentumot nem találok, de én is kíváncsi lennék rá. 

Interjú közben mesélték egy hazai banknál, hogy az agilis átállást kísérő fejlesztési igények jelentős része ilyen mélységű MNB-s regulációk miatt szükséges.

Talán van közöttünk hazai banki IT-ban dolgozó, aki részleteiben is ismeri. 

( gee v | 2021. 02. 09., k – 11:16 )

OK, hát ez eléggé rozoga.

Tegnap beléptem ujjlenyomattal.

Ma be akartam lépni, hogy zsver kolléga tanácsát követve átrendezzem a számláimat.

Ujjlenyomat: nem sikerült, add meg az mPIN-t.
mPIN: nem sikerült (azt hiszem, azt írta, hogy rossz a kód)
más módszerek - biometrikus azonosítás: ó, hát még nem állítottál be biometrikus azonosítást, nosza, most megteheted.
biometrikus azonosítás bekapcsolása: OK, add meg az mPIN-t.
mPIN: OK, biometrikus bekapcsolva.
ujjlenyomat: OK

Nice one

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( Tuschke | 2021. 02. 09., k – 19:53 )

Működik a George. Tegnap használtam.

( eff | 2021. 02. 10., sze – 09:59 )

Szerkesztve: 2021. 02. 10., sze – 09:59

Most epp mintha mukodne.

Help az nincs, de tooltip, amin disznek van a bezaras ikon, na az van...

( asdPro | 2021. 02. 11., cs – 15:40 )

Sub, mert engem is érdekel a téma, de kicsit OFF is, hátha valaki jobban képben van. A kérdésem, miért Bitcoin? Azon kívül, hogy az a "legnépszerűbb".  Az én megértésem szerint, a Bitcoin már "lejátszott" menet, azaz pl. https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html alapján az a userek vagy walletek 2,36%-nak van 1-nél több bitcoinja, tehát ezeknél a walleteknél összpontosul az egész Bitcoin "vagyon" majdnem 95%-a. Nincsenek pontos adataim, de valahogy a "valós" pénznél is így van, nem? Kevés gazdag kezében van sok pénz. 

A másik kérdés pedig, pontosan mi határozza meg, hogy fel- vagy lefelé megy az árfolyam? Ugye most Elon bevásárolt egy picit, és ettől felfelé ment, de ezt szimplán a hype generálta? Meg ugye új BTC csak nagyon kevés lesz naponta, így a meglévők cserélnek gazdát ha jól értem. Tehát akkor most miért 40x ezer dollár, míg korábban jóval "olcsóbb" volt, tehát "kevesebbet ért". Ha már itt tartunk, ha BTC-t veszel, kitől veszel? Aki éppen elad? Mi van ha senki nem ad el épp?

És végül, lehet hogy teljesen rosszul értelmezem, és most nem is a kriptopiac hasznosságára fókuszálok, de aki ebbe fektet, az tulajdonképpen attól várja a meggazdagodást, de legalábbis valamennyi nyereséget, hogy új belépők jönnek a hype következtében és így a berakott pénze többet fog érni, tehát minél később szállsz be, annál "rosszabb" (ami igazából neked jó is lehet, mert igaz, hogy 45 ezren szállsz be a BTC-be, de 1 hónap múlva lehet hogy 55 ezer lesz)? Mert ez nekem egy az egyben MLM/Piramisjáték/Tulipánláz szagú, és ezzel nem azt mondom, hogy rossz, és nem lehet vele keresni, sőt. Csak a magasztos érveléseket nem értem egyelőre, hogy köcsög bankok, meg hurrá decentralizáltság, stb., amikor az én szememben ez simán spekuláció.  Nem értek hozzá, sorry, viszont pár tízezerrel szívesen beszállnék én is :)

Nincsenek pontos adataim, de valahogy a "valós" pénznél is így van, nem? Kevés gazdag kezében van sok pénz. 

De.

A másik kérdés pedig, pontosan mi határozza meg, hogy fel- vagy lefelé megy az árfolyam?

Leegyszerűsítve: van egy rakás ember aki vesz, és egy csomó, aki elad. Van eladó BTC: 10, 11, 12 forintért, és van vételi ajánlat 8, 9, 10 forintért. A kettő találkozik, akkor 10 forintot ér a BTC. Te nagyon szeretnél BTC-t venni, ezért azt mondod, hogy 11 forintot is megadnál érte, hogy te kapd. Mivel van eladó BTC 11-ért, ezért azt megkapod, és az új árfolyam 11 forint. Jön valaki, aki szerint durranni fog a lufi, ezért kiszórja a BTC-jeit 8-ért, ezután hülye lenne bárki megvenni 10-ért, megy az árfolyam 8-ra.

Dióhályban arra megy az árfolyam, amelyik irányba tolják a fentiek alapján.

Ha már itt tartunk, ha BTC-t veszel, kitől veszel? Aki éppen elad? Mi van ha senki nem ad el épp?

Semmi, akkor nem tudsz venni, de ennek nagyon kicsi az esélye.

aki ebbe fektet, az tulajdonképpen attól várja a meggazdagodást, de legalábbis valamennyi nyereséget, hogy új belépők jönnek a hype következtében

Valaki igen. Mások azért, mert úgy gondoljáűk, hogy releváns szereplő lesz a piacon - most kell venni, amíg "'olcsó". Megint mások szabadságharcosok, köcsögbankok, anarchia, mittudomén. Vannak olyanok, akik a privacy miatt. Stb.

( uid_4263 v | 2021. 02. 19., p – 14:17 )

Az úgy van hogy az app beszélget a háttérrendszerrel. Ehhez nem kell google sem és play store sem.

Ha az app megkérdezi a háttérrendszertől hogy még jó vagyok-e, és nem a válasz, akkor lehet a definiált viselkedés az hogy makacsul kilép, nem indul el.

Frissitened kell arra, amit az Erste támogat.

( zeller | 2021. 03. 08., h – 12:19 )

Érik a bankváltás ...szák meg, mert a gyurira csrélik május 10-től a netbankot is... A mobilapp tapasztalatai alapján az is egy rakás f0s...

Kipróbáltad? A webes dettófos... A bemutató slide-ok vegyesen német, angol meg magyar felirattal, az utolsónál "setup.dashboardBtn" feliratú gombbal... Hitel nem látszik (a moratórium számla igen, mert az folyószámla jellegű "termék"), kártyalimit dettó 24 24 órás (se több, se kevesebb, és ezt a gyagyagyurika nem is tudja máshogy).

Gyakorlatilag a webes alkalmazás a mobilos "csempéket" rakja fel egy oldalra, kiegészítve néhány másik csempével.

Ahogy most kinéz, amilyen állapotban most van, úgy értelmes helyen talán a fejlesztői teszten sem ment volna át, de hogy ügyfélnek odaadni, hogy élesben nyomkodja, azt biztos, hogy nem...

Igen, több volt, mert abban bíztam, hogy a hiányzó funkciók idővel élesedni fognak a mobilos felületen is. Arra gondolni sem mertem, hogy a mobilalkalmazásban "elkövetett" visszalépéseket a webes felület is megörökli/megkapja, azaz abból is kiesik néhány olyan funkció/beállítás, ami eddig volt, és előnyként jelent meg az Erste mellett. Ezen előnyök kezdenek elfogyni, a PFM funkció nem ellensúlyozza a hiányukat (Egy 24-48 órás intervallumban beeső rendszeres terhelés a virtuális kártyára eddig egy, esetleg két limitállítást igényelt, most ez gyakorlatilag 3-5 alkalomra nő, miután a gyagyagyuri lesz a webes felület. A hitelem adatait meg nem tudom, hol fogom tudni megnézni - lehet, hogy hetente 1-2 alkalommal majd fogom hívni a telebankot, hogy nézzenek rá, olvassák be a pontos adatokat...? :-) Csak hogy "érezzék a törődést", minden alkalommal elmondva, hogy ez a funkció a netbankból hiányzik, azért telebankolok miatta.
De van még egy rakat egyéb "bammeg" dolog benne, ami miatt nem tetszik gyagyagyuri, amellett, hogy egy hazai fejlesztés lett kikukázva, és lett helyette ez a -ha jól tudom- osztrák bagázs által összelapátolt valami...

a PFM funkció nem ellensúlyozza a hiányukat

A PFM szerint 200 millió forintot költöttem az elmúlt hónapban, idk, szerintem nem ellensúlyoz az semmit. :D 

A hitelem adatait meg nem tudom, hol fogom tudni megnézni - lehet, hogy hetente 1-2 alkalommal majd fogom hívni a telebankot

Te jó Isten, minek? :D

",,majd fogom hívni a telebankot'' Te jó Isten, minek? :D" - hogy megkérdezzem hogy érzik magukat gyagyagyurika szülei :-) Nem, nem azért, hanem azért, hogy a gyagyagyuri webes felületen nem található információt (hitel állapota) megkérdezzem. Csak mert alkalmanként arra is rá szoktam nézni netbankon belül. Ha nem tudom megnézni, akkor sajnos a telebankos ügyintézők idejét fogom "rabolni"...

Nomostanm sokadszor: Oké, havonta egyszer (vagy fordulónapő időszak előtt meg után kétszer) rá lehet nézni most, a gyagyagyuriban meg nullaszor - ugyanis nem tud ilyet. És nem, nem káptalan a fejem, nem tartom észben, hogy adott hitelen mekkora a tartozás, és szeretném _bármikor_ megnézni. Akár annyiszor, ahányszor benézek a netbankba. Ami nem havi 1-2 alkalom.

A gond az, hogy nagyon kevés banknál van virtuális kártya, és erre szükségem lenne. Bár ha jobban belegondolok, ha a kártyalimitet le lehet vinni kellően alacsonyra (összeg meg tranzakciószám), akkor egy "sima" kártya is használható igy, mert normál használatra van másik, úgyhogy mégsem annyira gáz a helyzet...

Viszont a kártyád klónjával bármikor, bármennyit... Na ezt (klóngyártás) "nem nyert" a virtuális kártyával. Egyelőre kivárok, és gondolkodom, hogy mi legyen - egyelőre annyi van, hogy amikor szolgáltató terhel (kb. 2 napos időszakban valamikor), akkor reggel-este mobilbank, és megtomom 24 órával a kártyalimit érvényességét, és megnézem, hogy bejött-e már a terhelés.

Ez nagyjából hatszor annyi belépés/tranzakció, mint a korábbi volt, ennyiszer több DB-bejegyzés, log, illetve kapcsolódó csingilingi...