Kontraktbilag for Erhverv/A2P-beskeder
Gældende fra den 17. oktober 2026
Udvikler og automatisering er også omfattet af dette bilag. Profilen leverer API-tjenester til produktionsbrug for verificerede enkeltpersoner, der bruger personlige applikationer, hjemmeautomatiseringer eller AI-agenter; selskabsstiftelse eller virksomhedsoprettelse er ikke påkrævet. Krav til identitet, anvendelsestilfælde, afsender og relevant beskedregistrering gælder stadig. Al SMS/MMS sendt via API er A2P og oprettes særskilt fra personlige/forbrugerbeskeder. API-legitimationsoplysninger for udviklerprofilen giver ikke adgang til særskilt oprettede personlige mobiltjenester, forbruger-/P2P-tjenester eller eSIM-ressourcer til tale og tekst. Videresalg og brug hos kunder i leveringskæden kræver en vurdering til profilen Kommunikationsudbydere.
Dette bilag om erhvervs-/A2P-beskeder ("Erhvervsbilaget") gælder for beskeder sendt af eller for en virksomhed, organisation, profession, kampagne, nonprofitorganisation, offentlig myndighed eller anden afsender, der ikke er forbruger. Det supplerer Servicevilkårene og Politikken for acceptabel brug af beskeder.
1. Godkendelse før afsendelse
Erhvervsbeskeder må først påbegyndes, når MultiTEL har godkendt kunden, afsenderen, mærke (Brand), kampagne (Campaign), anvendelsestilfældet, nummertypen, afsendelsesmetoden og den forventede trafik. MultiTEL kan kræve juridisk navn, alternative navne, skatteidentifikatorer, stiftelsesdokumenter, reelle ejere, autoriserede repræsentanter, websteds- og privatlivspolitiks-URL'er, supportkontakter, eksempelbeskeder, opt-in-dokumentation, volumenprognoser og andre KYC- eller oplysninger om anvendelsestilfældet.
For Udvikler og automatisering er verificering baseret på den enkelte person og det faktiske applikationsbrugsscenarie. Selskabsdannelse, et EIN eller et virksomhedswebsted er ikke en generel betingelse for denne profil. Afsenderregistrering skal bruge en understøttet individuel eller anden berettiget registreringsmodel; fraværet af en virksomhed fritager ikke fra afsender-, samtykke- eller destinationskrav. Tilgængelighed bekræftes, før beskedfunktionen aktiveres.
Godkendelsen er begrænset til de indsendte oplysninger. En væsentlig ændring af brandet (Brand), begunstiget, meddelelsesformål, indholdskategori, opfordring til handling, samtykkeflow, listekilde, afsendelsesapplikation, nummer, land, volumen eller downstream-part kræver forudgående gennemgang og kan kræve en ny eller ændret registrering.
2. Registrering af varemærke, kampagne og afsender
Du skal gennemføre al registrering af afsender, Brand, Campaign, verificering af frikaldsnumre, kortkode, alfanumerisk afsender eller anden registrering, som kræves af MultiTEL, en operatør, et register eller lovgivningen. Registreringsoplysningerne skal identificere den faktiske enhed, som modtageren opfatter som afsender af beskeden, og det faktiske anvendelsesformål. Du må ikke bruge en anden parts Brand, skatte-id, Campaign, nummer eller godkendelse, medmindre MultiTEL udtrykkeligt godkender det forhold.
Indsendelse af en registrering garanterer ikke godkendelse, gennemløb, leveringsevne eller fortsat tjeneste. Registrets og operatørens behandlingstider, afgørelser, grænser, suspensioner og gebyrer kan ikke styres af MultiTEL alene.
3. Samtykke og tilmelding
Du skal indhente juridisk tilstrækkeligt samtykke, før der sendes beskeder, og opbevare dokumentation for, hvem der gav samtykke, hvornår, hvordan, til hvilken afsender, til hvilket formål, og hvilke oplysninger der blev præsenteret. Tilmeldingstekst skal være klar og tydelig og må ikke skjule væsentlige vilkår. Købte, lejede, scrapede, berigede, delte eller tredjepartslister må ikke bruges, medmindre hver modtagers samtykke lovligt og specifikt autoriserer beskeder fra den registrerede afsender, og brugen er godkendt af MultiTEL.
Hvor lovgivning eller brancheregler stiller skærpede krav til samtykke eller kræver skriftligt samtykke, skal du indhente det, før du sender. Du er ansvarlig for interne kontroller, som sikrer, at kontaktforbud og udelukkelseslister overholdes på tværs af alle applikationer, agenter, afdelinger og leverandører, der handler for brandet (Brand).
4. Krav til meddelelser
Beskeder skal svare til den godkendte anvendelse og de godkendte eksempler, identificere afsenderen, hvor det ikke nødvendigvis er åbenlyst, give de krævede oplysninger og kun bruge godkendte numre og links. Tilbagevendende programmer skal give de krævede oplysninger om hyppighed, hjælp, framelding samt besked- og datatakster. Markedsføring må ikke forklædes som en personlig samtale, en servicemeddelelse eller en transaktion.
Respektér STOP og alle andre rimelige anmodninger om tilbagekaldelse af samtykke straks og inden for gældende frister. HELP-svar skal give korrekte oplysninger om Brand og support. Send ikke flere kampagnebeskeder efter framelding, medmindre modtageren giver nyt gyldigt samtykke.
5. Adgang til portal og API
MultiTEL kan aktivere godkendt beskedtrafik for applikationer under profilerne Erhverv og Udvikler og automatisering via sin portal, API eller en anden specifikt autoriseret grænseflade. API-adgang er ikke automatisk og kan være begrænset af anvendelsesformål, rolle, IP-adresse, legitimationsoplysninger, nummer, gennemløbskapacitet eller andre kontroller. Du skal sikre legitimationsoplysninger, bruge adgang med færrest mulige rettigheder, føre logfiler, forhindre uautoriseret adgang fra brugere og applikationer og straks indberette kompromittering.
Du må kun bruge godkendte underleverandører til at drive din messaging, hvis de udelukkende handler for dit registrerede brand, er bundet af tilsvarende forpligtelser inden for compliance og sikkerhed og ikke tilfører uvedkommende afsendere eller downstream-kunder. Du er fortsat ansvarlig for deres adfærd.
6. Forbudt adfærd
Ud over politikken for acceptabel brug af meddelelser må du ikke:
- sende før den påkrævede godkendelse af brand (Brand), kampagne (Campaign), afsender eller anvendelsesformål;
- sende indhold eller bruge trafikmønstre, der er væsentligt uforenelige med en godkendelse;
- del en kampagne eller afsender mellem urelaterede brands;
- brug af personlige konti, forbrugerruter, uregistrerede numre eller en anden kundes konto for at omgå A2P-kontrol;
- rotere konti, numre, domæner, URL'er eller indhold for at omgå filtrering eller klager;
- sende til modtagere, hvis samtykke ikke kan dokumenteres;
- fortsætter med at sende efter en framelding, klage, suspension eller tilbagekaldelse af registrering; eller
- videresælge eller levere beskedtjenester til kunder længere nede i tjenestekæden under en Erhverv-profil.
7. Optegnelser, revision og klager
Opbevar registreringsindsendelser, godkendelser, samtykkedokumentation, tilmeldingsoplysninger, listekilder, beskedskabeloner, leveringsregistreringer, frameldinger, klager og blokeringsregistreringer i den periode, som loven kræver, og i mindst fire år. Udlever anmodede registreringer straks. MultiTEL kan kontrollere overholdelse direkte eller via en operatør eller et register og kan kræve korrigerende handling.
Du skal undersøge klager, stoppe berørt trafik, hvor det er relevant, bevare relevant bevismateriale og samarbejde med MultiTEL. Meld mistanke om svindel, kompromittering eller uautoriseret afsendelse med det samme.
8. Overvågning og håndhævelse
I det omfang loven tillader det, kan MultiTEL gennemgå metadata, indholdsindikatorer, repræsentativt indhold, URL'er, leveringsdata, klager, afmeldinger, registreringsdata og trafikmønstre. MultiTEL kan filtrere, begrænse, blokere, suspendere, omklassificere eller opsige meddelelsestjenester med det samme; kræve ny verifikation eller registrering; tilbagekalde API-adgang; og gemme godkendelses- og håndhævelsesregistre.
9. Gebyrer og ansvar
Du er ansvarlig for gebyrer for beskeder, operatører, registrering, kontrol, kampagner, numre, undersøgelser, afhjælpning og bøder, som kan henføres til din trafik. Der kan påløbe gebyrer fra opstrømsleddet for indsendte, filtrerede, afviste eller leverede beskeder. Du forbliver ansvarlig for overholdelse af reglerne, selv når MultiTEL eller en tredjepart hjælper med registrering eller teknisk implementering.