Ügyfélre kiterjedő mesterséges intelligencia API-kulcsok: A bérlők, a költségvetések és a visszaélések elkülönítése a szolgáltatói kulcs kiterjesztése nélkül

Amikor egy termék lehetővé teszi sok ügyfél számára, hogy mesterséges intelligencia modelleket hívjon, gyakran rossz primitív az upstream szolgáltatói kulcs. A szolgáltatói kulcs általában fiókot, projektet, munkaterületet vagy szolgáltatásfiókot jelöl. A terméknek valami szűkebbre van szüksége: egy ügyféloldali kulcsra, amely azonosít egy bérlőt, ügyfelet, alkalmazást, környezetet, modellszabályzatot, költségvetést és ellenőrzési szabályt.

Az ügyfelek által hatókörű AI API-kulcsoknak ez a célja. Az átjáró kiadja a kulcsot, hitelesíti a kéréseket, alkalmazza a házirendet, méri a használatot, majd rejtett hitelesítő adatok segítségével felhívja a upstream szolgáltatókat. A downstream ügyfelek soha nem kapják meg a szolgáltatói kulcsot. Stabil szerződést kapnak az Ön platformjával.

Olvasó probléma: Ügyfél elszigetelése ügyfelenként egy szolgáltatói projekt nélkül

A SaaS-építőknek, ügynökségeknek és viszonteladói platformoknak általában gyakorlati kérdésekre kell válaszolniuk, mielőtt felfedhetik a mesterséges intelligencia-hozzáférést:

• Melyik ügyfél hozta létre ezt a használatot?
• Melyik alkalmazás, környezet vagy integráció kezdeményezte a hívást?
• Mely modellek és módozatok engedélyezettek?
• Mennyit költhet ez az ügyfél ebben a hónapban?
• Mi történik, ha egy kulcs kiszivárog?
• Felfüggeszthető ez az ügyfél anélkül, hogy ez mindenki mást érintene?
• A használat később összeegyeztethető a szolgáltatói jelentésekkel?

A szolgáltató oldali projektek és munkaterületek segíthetnek, de nem mindig a megfelelő egység minden továbbfelhasználó számára. Ügyfelenként egy upstream határ létrehozása javíthatja a kemény elkülönítést és a jelentéskészítést, de emellett többletköltséget, kvótatöredezettséget, hitelesítő adatok szétterülését és több egyeztetési munkát is eredményez.

Az átjáró által kiadott kulcs ügyfélszintű vezérlőpontot ad a terméknek, még akkor is, ha az upstream hitelesítő adatokat összegyűjtik. Támogatja az erősebb módokat is, mint például a bérlőhöz kötött szolgáltatói hitelesítési adatok vagy a saját kulcs behozatala, amikor az ügyfélnek szerződéses szétválasztásra, lakóhelyhatárokra vagy közvetlen szolgáltatói fióktulajdonra van szüksége.

Tények, ajánlások és előrejelzések

Tények

• Az OpenAI projektek támogatják a tagokat, a szolgáltatásfiókokat, az API-kulcsokat, a használati korlátokat, a költségvetéseket és a projekt-erőforrásokat. Ez hasznossá teszi a projekteket felfelé irányuló határként, de nem automatikusan minden végfelhasználó számára megfelelő primitív elemként.
• Az OpenAI használati jelentések csoportosíthatják a használatot dimenziók szerint, például projekt, felhasználó, API-kulcs, modell, köteg és szolgáltatási szint szerint. A SaaS-visszaterheléshez továbbra is össze kell kapcsolni a szolgáltatói rekordokat a termék tulajdonában lévő ügyfél-azonosítókkal.
• Az antropikus munkaterületek különválasztják az API-erőforrásokat használati eset, csapat, részleg, projekt vagy termék szerint. Az API-kulcsok ahhoz a munkaterülethez vannak kötve, ahol létrehozták őket, és nem helyezhetők át a munkaterületek között.
• Az antropikus használat és költségjelentés támogatja az API-kulcs, a munkaterület, a modell, a szolgáltatási szint, a kontextusablak, az adatok tartózkodási helye és a sebességgel kapcsolatos opciók szerinti csoportosítást, a költségek napi USD-csoportokban térülnek meg.
• A Google Gemini API kulcsútmutatója a kulcsok korlátozását javasolja, a Gemini API kulcsok pedig alapértelmezés szerint a Generative Language API-ra vannak korlátozva. A telepítés alakjától függően alkalmazáskorlátozások, például IP-címek állnak rendelkezésre.
• Az OWASP útmutató az API-kulcsokat a védett végpontok kötelező vezérlőjeként kezeli, és azt mondja, hogy a kulcsokat vissza kell vonni, ha az ügyfelek megsértik a használati megállapodásokat.
• Az OWASP titkokra vonatkozó útmutatása hangsúlyozza a legkevesebb jogosultságot, a visszavonást, amikor már nincs szükség a titkokra, vagy veszélybe kerül, valamint az automatikus forgatást a megvalósítási hibák csökkentése érdekében.

Javaslatok

• Az átjáró által kibocsátott ügyfélkulcsokat használja szabályzatkezelőként, ne csak hitelesítési tokeneket.
• Tartsa rejtve az upstream szolgáltató hitelesítő adatait a későbbi ügyfelek elől.
• Kéréskor írjon átjáróhasználati főkönyvet, mielőtt a szolgáltatói irányítópultokra hagyatkozna.
• Használja szelektíven a szolgáltatói projekteket vagy munkaterületeket magas kockázatú, nagy volumenű, szabályozott, lakóhely-érzékeny vagy szerződéses különálló ügyfelek számára.
• A kulcsok elforgatását átfedő munkafolyamatként hozza létre, nem pedig azonnali törési eseményként.

Előrejelzések

• További szolgáltatók szélesebb körű felhasználási csoportosítást és költségkeret-szabályozást tesznek elérhetővé, de a terméktulajdonos ügyfél-hozzárendelés továbbra is szükséges lesz a SaaS-számlázáshoz és a viszonteladói jelentésekhez.
• A viszonteladói és ügynökségi platformok egyre inkább kereskedelmi objektumként fogják kezelni az átjárókulcsokat: tervekhez, hitelegyenlegekhez, hatókörökhöz és támogatási munkafolyamatokhoz kötve.
• A szigorú megfelelési vagy beszerzési igényű ügyfelek a BYOK-ot vagy a szolgáltatói fiók tulajdonjogát kérik, míg a legtöbb hétköznapi ügyfél a felügyelt átjáró-szerződést részesíti előnyben.

Az átjáró kulcsobjektum

Az ügyfél-hatókörű kulcsnak strukturált házirend-objektummá kell feloldódnia. Minimálisan modellezze a kulcsot többként, mint egy hash és egy név.

{
  "key_id": "key_01J9...",
  "tenant_id": "bérlő_acme",
  "customer_id": "cust_4812","application_id": "app_support_bot",
  "environment": "termelés",
  "tulajdonos": {
    "type": "service_account",
    "id": "svc_support_ai"
  },
  "model_profile_id": "profile_support_standard",
  "allowed_modalities": ["text", "image_input"],
  "tool_policy_id": "tools_readonly_kb",
  "monthly_budget": {
    "currency": "USD",
    "összeg": "500.00"
  },
  "rate_limits": {
    "requests_per_minute": 120,
    "input_tokens_per_minute": 250000,
    "kimeneti_tokens_per_perc": 80000
  },
  "retention_policy": "metadata_only",
  "status": "aktív",
  "created_at": "2026-09-05T10:00:00Z",
  "last_used_at": null
}

A pontos mezők változhatnak, de az elv nem szabad: minden bejövő kérés feloldja a kulcsot a bérlői szabályzatba a feladás előtt. A hitelesítés azt válaszolja, hogy „ki hív?” A házirendi állásfoglalás azt a választ adja, hogy „mit tehet ez a hívó, mennyit költhet, hová vezethet a kérés, és mit kell naplózni?”

Itt számít a szemantikai termékstratégia is. Előfordulhat, hogy egy AI API-t ügynökségek számára értékesítő platformnak ügyfél- és kampánydimenziókra van szüksége. Előfordulhat, hogy egy fejlesztői eszköznek munkaterület- és adattárdimenziókra van szüksége. Előfordulhat, hogy a viszonteladónak olyan külső ügyfél-azonosítókra van szüksége, amelyek megegyeznek a számlázási rendszerével.

Kulcskészítési munkafolyamat

A kulcs létrehozásának elég determinisztikusnak kell lennie az automatizáláshoz, és elég szigorúnak kell lennie a biztonsági felülvizsgálathoz.

1. Először hozza létre az ügyfélrekordot

Ne hozzon létre árva kulcsokat. A kulcsnak egy bérlőhöz és egy ügyfélrekordhoz kell tartoznia, mielőtt létezne. Viszonteladói platformok esetén az ügyfélrekordnak tartalmaznia kell a viszonteladó CRM-jéből vagy számlázási rendszeréből származó külső azonosítókat, terv metaadatokat, szükség esetén adó- vagy számlacsoportosítást, valamint egy állapotmezőt, amely felfüggesztheti az összes gyermekkulcsot.

2. Modellprofil csatolása

A modellprofil leképezi az ügyfelek számára elérhető modellneveket a szolgáltatói modellekre és képességekre. Például a support-standard lehetővé teheti a kiegyensúlyozott szövegmodellt, a képbevitelt és a kód végrehajtását. A research-prémium lehetővé teheti a hosszú kontextusú modelleket, a webes keresést és a magasabb kérésenkénti plafont.

Ne kényszerítse a downstream alkalmazásokat a hard-code szolgáltatói modellazonosítókra. Az átjáróprofil segítségével kezelheti a rendelkezésre állást, a tartalékot, az árakat és az elavulást.

3. Állítsa be a ráfordítási és díjszabási korlátokat

Használja együtt a költségkeretet és a díjkorlátokat. A havi költségvetés megakadályozza, hogy a számlák idővel kárt okozzanak. A díjkorlátok megakadályozzák, hogy a hirtelen visszaélések, az újrapróbálkozási viharok vagy a véletlen hurkok percek alatt felemészsszék a teljes költségvetést.

A hasznos vezérlők a következők:

• Az ügyfél havi költségkerete.
• Napi puha sapka az anomáliák észleléséhez.
• Kulcsonkénti kérések aránya.
• Bemeneti és kimeneti token sebesség.
• Kérésenkénti maximális becsült költség.
• Eszközspecifikus korlátok a hosztolt kereséshez, fájlfeldolgozáshoz vagy kódvégrehajtáshoz.

A költségkeret végrehajtásának le kell foglalnia a becsült költséget a feladás előtt, a tényleges költséget a befejezés után kell rendeznie, és fel kell szabadítania a fel nem használt tartalékot. Ez összekapcsolja a kulcsfontosságú szabályzatot az AI API számlázásával ahelyett, hogy a számlázást késleltetett jelentési feladatként kezelné.

4. Generálja és tárolja helyesen a Titkot

Egyszer jelenítse meg az egyszerű szöveges titkot. Csak erős hash-t tároljon, valamint egy rövid előtagot vagy ujjlenyomatot a támogatás kereséséhez. Az előtag segít a támogató csapatoknak azonosítani „a 8F2A-ra végződő kulcsot” anélkül, hogy látnák a titkot.

A tipikus tárolási minta a következő:

• key_id: stabil adatbázis-azonosító.
• secret_hash: a teljes titok kivonatolása megfelelő jelszó vagy token kivonatolási stratégiával.
• titkos_prefix: rövid, nem érzékeny megjelenítési előtag.
• ujjlenyomat: determinisztikus azonosító az ellenőrzési kereséshez.
• created_by: a kulcsot létrehozó felhasználó vagy Partner API-kliens.
• állapot: aktív, lemerülő, visszavonva, karanténba helyezve, lejárt.

Soha ne tároljon upstream szolgáltatói kulcsokat az ügyfélkulcs objektumon. A szolgáltató hitelesítő adatai egy külön hitelesítő adattárba tartoznak, saját hozzáférési szabályokkal.

Kérés időbeli végrehajtása

Az átjárónak minden modellhívást házirendi döntésként kell kezelnie, amelyet egy szolgáltatói feladás követ. A kérés gyakorlati elérési útja így néz ki:

1. Elemezze a bemutatott átjárókulcsot.
2. Keresse meg a kulcs kivonatát és állapotát.
3. Bérlői, ügyfél-, alkalmazás-, környezet-, tulajdonos- és modellprofil megoldása.
4. Ellenőrizze, hogy a bérlő és az ügyfél aktív-e.
5. Érvényesítse a kért modellálnevet, modalitást, eszközöket, megőrzési módot, régiót és szolgáltatási szintet.
6. A kérés költségének és tartalék költségkeretének becslése.
7. Ellenőrizze az aránykorlátokat és a visszaélési küszöböket.
8. Válassza ki az upstream hitelesítési módot: összevont, bérlőhöz kötött vagy BYOK.
9. Kiküldés a szolgáltatónak.
10. Rögzítse a felhasználást, a költségeket, a szolgáltatói hivatkozásokat, a hibákat és a biztonsági jelzéseket.
11. Egyeztesse a költségvetési foglalást, és írja meg a zárókönyvi eseményt.

Ez a sorrend az átjárót tartja felelősnek az ügyfélszerződésért. A szolgáltatói irányítópultok egyeztetési bemenetekké válnak, nem pedig az igazság egyetlen forrásává.

A későbbiekben valóban hasznos főkönyvi mezők használata

Az átjáró főkönyvnek elegendő részletet kell megőriznie ahhoz, hogy megválaszolja a támogatási, számlázási, visszaélési és útválasztási kérdéseket anélkül, hogy alapértelmezés szerint nyers azonnali tárolásra lenne szüksége.

A hasznos mezők a következők:

• request_id és trace_id.
• bérlőazonosító, customer_id, application_id és key_id.
• Végfelhasználói azonosító, lehetőleg álnévvel, ahol lehetséges.
• Az ügyfél által kért modellálnév.
• Megoldott upstream szolgáltató és modell.
• Bemenet, kimenet, érvelés, gyorsítótárazott, hang-, kép-, videó- és eszközhasználat, ahol lehetséges.
• Jelzett költség, lefoglalt összeg, elszámolt költség, pénznem és árazási katalógus verziója.
• A szolgáltatói kérelem azonosítója, a használati jelentés hivatkozása, a projekt, a munkaterület vagy az API-kulcscsoport dimenziója, ha elérhető.
• A megőrzési szabályzat érvényes.
• Biztonsági, visszaélési vagy politikai döntési kódok.
• Hibakategória, és próbálkozzon újra a metaadatokkal.

Ez a struktúra támogatja a visszaterhelést, az ügyfélszolgálatot, az incidensre adott választ és egy API-kulcskezelési munkafolyamatot, amely meg tudja válaszolni a „mit csinált ez a kulcs?” anélkül, hogy lelepleznék a nem kapcsolódó bérlőket.

Hitelesítési módok: Összevont, Bérlőhöz kötött és BYOK

Pooled Provider hitelesítő adatok

Alapértelmezett módban sok ügyfélkulcs kisebb szolgáltatói hitelesítési adatokon halad keresztül. Ez működésében egyszerű, és csökkenti a szolgáltató oldali terjeszkedését. Akkor működik, ha az átjáró erős bérlői hozzárendeléssel, költségkeret-érvényesítéssel, sebességkorlátozással, visszaélések elkülönítésével és gyorsítótár-határellenőrzéssel rendelkezik.

A kompromisszum az, hogy a szolgáltató oldali jelentések csak az átjáró hitelesítő adatait vagy a szolgáltatói projektet jeleníthetik meg. Ügyfélszintű számlázási és elemzési adatok készítéséhez a szolgáltatói rekordokat vissza kell kapcsolnia az átjáró főkönyvi rekordokhoz.

Bérlőhöz kötött szolgáltatói hitelesítési adatok

Nagyobb vagy kockázatosabb bérlők esetén kösse a bérlőt egy dedikált szolgáltatói projekthez, munkaterülethez, szolgáltatásfiókhoz vagy kulcshoz. Ez erősebb upstream elkülönítést biztosít, és leegyszerűsítheti a szolgáltató oldali jelentéstételt. Kemény kvóta-visszatartást is biztosíthat, ha a szolgáltató támogatja a korlátokat ezen a határon.

A költség a működés bonyolultságától függ. Az üzembe helyezés, a rotáció, a szolgáltatói korlátok, az incidensekre adott válaszok és az egyeztetés mostantól több upstream objektumon keresztül történik.

Hozza magával a saját kulcsát

A BYOK akkor lehet hasznos, ha az ügyfeleknek kell a szolgáltatói fiók tulajdonosa, saját szolgáltatói szerződést kell kötniük, vagy a szolgáltatói számlázást külön kell tartaniuk. Az átjáró továbbra is alkalmazza a modellprofilokat, az útválasztási szabályzatot, az elemzéseket és az alkalmazásszintű vezérlőket, ahol lehetséges.

A kompromisszum a támogatás összetettsége. Az egyes ügyfelek szolgáltatói fiókjai eltérő modellhozzáféréssel, kvótákkal, árképzéssel, megőrzési beállításokkal és incidens állapottal rendelkezhetnek. Az átjárónak ezeket a különbségeket egyértelműen észlelnie és meg kell magyaráznia.

Visszavonás és karantén

A visszavonásnak azonnal blokkolnia kell az új ügyfélkulcsra vonatkozó kéréseket, anélkül, hogy a független felfelé irányuló szolgáltatói hitelesítési adatokat cserélné. Ez a virtuális kulcsok egyik fő előnye.

Használjon külön állapotokat a különböző működési műveletekhez:

• aktív: a kérések engedélyezettek.
• leürítés: a régi kulcsot elfogadja a forgatási ablak, de figyelmeztetések és ellenőrzési események kerülnek kiadásra.
• visszavonva: az új kérések véglegesen elutasításra kerülnek.
• karanténba: az új kérések blokkolva vannak visszaélés, fizetés, szabályzat vagy incidensre adott válasz miatt.
• lejárt: a kulcs túllépte élettartamát, és ki kell cserélni.

A karanténnak visszafordíthatónak kell lennie, ha az incidens megoldódott. A visszavonás általában nem lehet visszafordítható, mert a régi titkok visszaállítása növeli a zavart és a kockázatot.

Ha egy kulcs megsérti a használati szabályzatot, naplózza az okot, a szereplőt, az időpontot és a végrehajtás hatályát. Ha a döntés automatizált volt, őrizze meg a szabály verzióját és az azt kiváltó jeleket. Ez tényszerűvé teszi az ügyfelek beszélgetéseit.

Forgatás a termelés megszakítása nélkül

A billentyűforgatáshoz kétbillentyűs átfedéses munkafolyamatot kell alkalmazni:

1. Hozzon létre cserekulcsot ugyanazzal az ügyféllel, alkalmazással, modellprofillal és korlátokkal, hacsak a kezelő nem változtatja meg ezeket szándékosan.
2. Egyszer jelenítse meg az új titkot.
3. Jelölje meg a régi kulcsot leürítésként.
4. Elfogadja mindkét kulcsot korlátozott ideig, például 7, 14 vagy 30 napig, az ügyfél tervétől és kockázatától függően.
5. Használati figyelmeztetéseket adjon ki az ürítőkulcson.
6. Értesítse a tulajdonost vagy a Partner API-ügyfelet, ha a régi kulcs még mindig használatban van a határidőhöz közel.
7. Vissza vissza a régi kulcsot az ablak végén.
8. Tartsa meg a hozzárendelést mindkét kulcsazonosítóhoz ugyanazon ügyfél és alkalmazás alatt.

Ezzel elkerülhető az általános hibaüzenet, amikor a biztonsági fejlesztés termeléskieséssé válik. A rotáció továbbra is ellenőrzés, de operatív munkafolyamattá válik bizonyítékokkal és határidőkkel.

Partner API felület

Ha a downstream platformok programozottan kezelik az ügyfeleket, tegye közzé a kulcsfontosságú műveleteket a Partner API-n keresztül. Az API-nak támogatnia kell az idempotenciakulcsokat és az ellenőrzési eseményeket, mert a kiépítés gyakran a számlázási, beépítési vagy CRM-munkafolyamatokon belül történik.

Minimális végpontok:

• POST /customers: ügyfelet hozhat létre vagy módosíthat.
• POST /customers/{customer_id}/keys: hozzon létre egy kulcsot.
• GET /customers/{customer_id}/keys: a kulcsok és állapotok listája.
• PATCH /keys/{key_id}: frissítse a hatóköröket, a tulajdonost, a korlátokat, a modellprofilt vagy az állapotot.
• POST /keys/{key_id}/rotate: hozzon létre cserét, és jelölje meg a régi kulcsot leürítésként.
• POST /keys/{key_id}/revoke: azonnali visszavonás.
• GET /customers/{customer_id}/usage: a használat és a költségek visszaadása időtartomány, kulcs, alkalmazás, modell vagy végfelhasználói dimenzió szerint.

Minden mutáló kérésnek el kell fogadnia egy idempotencia kulcsot. Minden változtatásnak fel kell írnia egy audit eseményt a szereplő, a cél, az előtte és utána mezőkkel, a forrás IP-címével vagy a kliens azonosítójával, valamint az indoklással, ha lehetséges.

Mikor használjunk szolgáltatói projekteket vagy munkaterületeket

Ne kezelje az átjárókulcsokat és a szolgáltatói határokat egymást kizáróként. Különféle problémákat oldanak meg.

Használja az átjárókulcsokat a normál ügyfélszintű vezérléshez:

• Ügyfélenkénti hozzárendelés.
• Alkalmazásonkénti kulcsok.
• Költségkeret- és díjkorlátok.
• Gyors felfüggesztés.
• Rotációs munkafolyamatok.
• Használatelemzés és viszonteladói jelentés.

Szállítói projektek, munkaterületek vagy dedikált szolgáltatói hitelesítési adatok hozzáadása, ha az ügyfélnek erősebb elválasztásra van szüksége:

• Magas havi mennyiség, amely külön kvótákat érdemel.
• Szabályozott munkaterhelések kifejezett tartózkodási vagy megőrzési követelményekkel.
• Szerződéses számlák szétválasztása.
• Kemény szolgáltatóoldali költségkeret vagy kvóta-backstop.
• Dedikált visszaélés-felügyeleti vagy biztonsági felülvizsgálati határok.
• Ügyfél tulajdonában lévő szolgáltatói fiókok a BYOK-on keresztül.

A gyakorlati alapértelmezés az átjáró által kényszerített elszigetelés szelektív felfelé irányuló kemény határvonalakkal. Ez egyszerűvé teszi a közös utat, miközben megőrzi az eszkalációs útvonalat azon ügyfelek számára, akiknek nagyobb szétválasztásra van szükségük.

Megvalósítási ellenőrzőlista

• Határozzon meg egy ügyfélkulcs-sémát bérlővel, ügyféllel, alkalmazással, környezettel, tulajdonossal, modellprofillal, korlátokkal, megőrzési szabályzattal és állapottal.
• A titkok kivonatolása nyugalmi állapotban, és a nyílt szöveg csak egyszer jelenik meg.
• Válassza le az átjárókulcsokat a felsőbb szintű szolgáltatói hitelesítő adatok tárolójától.
• Minden kérést rendezzen be házirendbe a feladás előtt.
• A szolgáltatói hívások előtt tartsa le a költségkeretet, és egyenlítse ki a végső felhasználást követően.
• Rögzítse a felhasználást az ügyféllel, kulcstal, modellálnévvel, upstream modellel, token kategóriákkal, eszközhasználattal, jegyzett költséggel, elszámolt költséggel és szolgáltatói referenciákkal.
• Aktív, ürítő, visszavont, karanténba helyezett és lejárt állapotok megvalósítása.
• Támogatja a két billentyű elforgatását.
• Nyomja meg a Partner API műveleteit idempotenciakulcsokkal.
• Csak akkor használjon szolgáltatói projekteket vagy munkaterületeket, ahol azok működési költsége indokolt.

Intézhető következtetés

A mesterséges intelligencia eléréséhez szükséges ügyfelek elkülönítésének általában az átjárókulcsnál kell kezdődnie, nem a szolgáltatói kulcsnál. Az átjáró kulcsa az ügyfelek felé irányuló szerződés: megnevezi a bérlőt, ügyfelet, alkalmazást, modellprofilt, költségvetést, díjkorlátot, megőrzési szabályt és ellenőrzési szabályzatot. A szolgáltató kulcsa egy megvalósítási részlet a szerződés mögött.

Ez az architektúra lehetővé teszi a SaaS-készítők és viszonteladói platformok számára a gyors visszavonást, a pontos hozzárendelést, az ügyfélenkénti költségkeretet, a szabályozott rotációt és a hasznos használati elemzést anélkül, hogy alapértelmezés szerint minden ügyfél számára egy upstream szolgáltatói projektet hoznának létre. Használjon felsőbb szintű projekteket, munkaterületeket, bérlőhöz kötött hitelesítési adatokat vagy BYOK-ot, ha a kockázat, a mennyiség, a lakóhely vagy a szerződés megköveteli. A szokásos útvonalhoz kényszerítse ki az ügyfelek elkülönítését az átjáró főkönyvében és a házirend-motorban, majd ezt követően hangolja össze a szolgáltatói rekordokat.

Kapcsolódó olvasmány

• partneri API-k és ügyfelek számára kulcs-szolgáltatás kredit