MNP in Germany
In Germany, the regulatory body Bundesnetzagentur (Federal Network Agency) is represented by an independent Clearing house for Communications Services (ICCS) and is crucial in managing the porting process between the donor and recipient service providers.
MNP process is triggered by the Recipient Service Provider when the Port-IN request is created and submitted to ICCS, which creates as result the Port-Out request to the Donor Service Provider (from which the phone number will be migrated). ICCS handles the communication between the Port-IN and Port-Out requests.
From the Customer perspective:
- The MNP process in Germany can take a minimum of 6 business days from the day the Port-IN is requested to a maximum of 123 business days.
- Port-Out request is possible up to 3 months after termination of the contract with the Partner.
MNP Lifecycles
MNP-OUT
At a higher level, the MNP-OUT (Port-OUT) request begins on the donor’s side in pending status, and at this point, the carrier can prevent the request from moving to pending status in the case of due payments. Following this state, typical validations occur from 1GLOBAL and communications between the current carrier, the new carrier, and ICCS. This process results in either the request to progress to a scheduled state or be rejected. Once scheduled, the customer can cancel the request and remain with their current provider. If no cancellation is made, the portability process is initiated, and 1GLOBAL facilitates communication with relevant entities like the ICCS.
MNP-IN
The MNP-IN (Port-In) process is initiated when the customer requests to port their number to the new provider after informing the donor. The new provider creates a draft MNP in order, which is validated against the donor’s request and then transitions to a pending state. The ICCS processes the request, and the donor provider can accept and send it to scheduled status or reject it and send rejected status as described in MNP OUT flow. If accepted, the order moves to a scheduled status, where the customer can cancel on the new carrier’s side for a specified period. Once the porting request is locked, the porting process can't be changed anymore. When the scheduled date is met, it goes to processing status, which consists of the de-provisioning of the phone number in the donor’s carrier side and the provisioning on the new provider, who provides the service, in this case, 1GLOBAL and its Partner. Finally, the request is marked as status-completed, and the customer is notified. 1GLOBAL will facilitate the process of moving the phone number to the customer’s new profile.
Required Customer Data
Port-OUT Request
Personal Account
- First Name
- Last Name
- Birthdate
- Address
- Phone Number to port
- Current Service Provider (Donor)
- Scheduling options:
- Specific Date (at least 6 business days ahead and no longer than 123 business days in the future)
- Porting as soon as possible (Typically 6 business days)
Business Account
- Business Name
- Business Registration Number
- Business Address
- Phone Number to port
- Current Service Provider (Donor)
- Account ID - Current Service Provider
- Scheduling options:
- Specific Date (at least 6 business days ahead and no longer than 123 business days in the future)
- Porting as soon as possible (Typically 6 business days)
Port-IN Request
Personal Account
- First Name
- Last Name
- Birthdate
- Address
- Phone Number to port
- Current Service Provider (Donor)
- Scheduling options:
- Specific Date (at least 6 business days ahead and no longer than 123 business days in the future)
- VTEN (supported if contract termination date no longer than 123 business days in the future)
Business Account
- Business Name
- Business Registration Number
- Business Address
- Phone Number to port
- Current Service Provider (Donor)
- Account ID - Current Service Provider
- Scheduling options:
- Specific Date (at least 6 business days ahead and no longer than 123 business days in the future)
- VTEN (supported if contract termination date no longer than 123 business days in the future)
API endpoints
Endpoints were added as Mandatory and Optional. The reasoning for this clustering is explained as follows:
- Mandatory means they are part of the MNP core process and without them, it is not possible to go through the process from the start until the end.
- Optional means they are available to be considered by the Partner to enable specific business, customer service processes supporting the MNP process.
| Endpoint | Required |
|---|---|
| List all service providers | Mandatory |
| Get phone-number-id from subscription | Mandatory |
| Create a new port order (Port-In) | Mandatory |
| Request cancelation of the Porting | Mandatory |
| Port-Out specific: Enables Opt-In | Mandatory |
| List all Porting requests | Optional |
| Get a specific Porting | Optional |
| Get a MSISDN porting opt-in config | Optional |
| Patch a Porting processing action | Optional |
Germany Error Codes Mapping
| Rejection Reason | Reason | Action |
|---|---|---|
request_not_readable | Request format invalid or unreadable | Fix payload structure and submit a new request |
unknown_mobile_number | Mobile number not found with donor operator | Verify MSISDN and donor provider, then submit a new request |
wrong_customer_type | Customer type mismatch (private vs business) | Correct donor_details.account.type and resubmit |
wrong_name | Name does not match provider records | Correct donor-matching customer data and resubmit |
wrong_birth_date | Birth date does not match | Correct donor-matching customer data and resubmit |
wrong_customer_number | Customer number incorrect | Correct account number and resubmit |
wrong_name_and_birth_date | Both name and birth date incorrect | Correct both values and resubmit |
wrong_name_and_customer_number | Name and customer number incorrect | Correct both values and resubmit |
pre_requirements_not_fulfilled | Resolve donor-side prerequisites before submitting a new request | |
missing_opt_in | No opt-in set for early porting | Enable donor opt-in, then submit a new request |
duplicate_portation_request | Duplicate request from same provider | Wait for the existing request to finish or be canceled |
portation_already_in_progress | Another porting request already in progress | Do not retry until the active case ends |
portation_request_too_early | Request submitted too early | Submit when the case becomes eligible |
portation_request_too_late | Request submitted after allowed timeframe | Review termination timing before any new request |
requested_portation_date_too_early | Requested porting date is too early | Choose a later date and submit a new request |
requested_portation_date_too_late | Requested porting date too far in future | Choose an earlier valid date and submit a new request |
requested_portation_date_unrealizable | Requested date cannot be executed | Choose another valid date and submit a new request |
no_portation_available | Portability not possible | Escalate for manual review before retrying |
portation_origin_different_sp | Wrong donor provider specified | Correct donor provider and submit a new request |
other | Other | Review rejection message and triage manually |
cancellation_too_late | Cancellation too late | Do not retry cancellation; the case returns to scheduled if declined |
Warning on System Logic & Automated Retries
No DE rejection enum in the verified source set is marked for automatic retry.
Do not build manual retry loops that blindly replay rejected submissions. For DE, the safe integration pattern is:
- inspect the rejection enum and any message
- correct the underlying data, donor selection, opt-in state, or schedule
- create a new request only after the issue has been fixed
For cancellation_too_late, there is no retry path. The cancellation attempt is declined and the request remains in scheduled.