تعريف الموافقة الصريحة

تعريف الموافقة الصريحة

Explicit Consent Definition

الحالة: تعريف ومعيار أساسي

التصنيف: التعاريف والمعايير — التعاقدات والموافقات

النطاق: جميع الموافقات والإقرارات والقبولات الإلكترونية التي تصدر من المستخدمين داخل منظومة بال لانسر (PalLancer) ويترتب عليها أثر تعاقدي أو قانوني أو تشغيلي أو مالي يتطلب موافقة المستخدم وفق القانون أو العقد أو السياسات المعتمدة.

أولًا: التعريف

لأغراض منظومة بال لانسر (PalLancer)، يُقصد بـ «الموافقة الصريحة» التعبير الواضح والإيجابي والقابل للتوثيق عن إرادة المستخدم في قبول إجراء أو مستند أو شرط أو التزام محدد، بعد إتاحة المعلومات الجوهرية اللازمة لفهم طبيعة ما تتم الموافقة عليه وآثاره الأساسية.

ويجب أن تكون الموافقة الصريحة مرتبطة بمحل محدد وقابلة للنسبة إلى الشخص أو الحساب أو الممثل المخول الذي أصدرها.

ولا يُعد السكوت أو عدم الرد أو مجرد استمرار استخدام المنظومة، بذاته، موافقة صريحة على إنشاء عقد أو تعديل التزام جوهري أو قبول عرض سعر أو نقل حق أو إصدار تفويض مالي، ما لم يسمح القانون أو العقد بآلية إجرائية محددة مسبقًا تحقق شروطًا أخرى مشروعة لا تتعارض مع هذا التعريف.

ثانيًا: العناصر الأساسية للموافقة الصريحة

حتى تُعامل الموافقة باعتبارها موافقة صريحة داخل بال لانسر، يجب، بحسب طبيعة الإجراء، أن تتوافر فيها العناصر الآتية:

1. أن تصدر من المستخدم نفسه أو من ممثل يملك صلاحية صحيحة.
2. أن تتعلق بإجراء أو مستند أو التزام محدد.
3. أن تكون مسبوقة بإتاحة المعلومات والشروط الجوهرية المتعلقة به.
4. أن تصدر من خلال إجراء إيجابي واضح يدل على إرادة المستخدم.
5. أن تكون قابلة للتوثيق والإثبات.
6. أن ترتبط بالنسخة المحددة من المستند أو الشرط محل الموافقة.
7. ألا تكون ناتجة عن تصميم مضلل أو إخفاء متعمد لمعلومة جوهرية.
8. أن تصدر ضمن السياق والصلاحية المناسبة للشخص الذي أصدرها.

ولا يكفي مجرد وجود المستند أو الشرط داخل المنظومة لإثبات قبول المستخدم له.

ثالثًا: الإجراء الإيجابي

يجب أن تتضمن الموافقة الصريحة إجراءً إيجابيًا من المستخدم متناسبًا مع أهمية الالتزام.

وقد يشمل ذلك، بحسب الحالة:

1. الضغط على زر قبول واضح.
2. اختيار مربع موافقة غير محدد مسبقًا.
3. توقيع إلكتروني.
4. إدخال رمز تحقق أو تأكيد.
5. اعتماد مستند أو نسخة معينة.
6. أي إجراء إلكتروني آخر يثبت بصورة مناسبة إرادة المستخدم.

ولا يجوز استخدام مربع موافقة محدد مسبقًا أو تصميم يجعل الرفض أو عدم الموافقة غير واضح بصورة غير معقولة عندما تكون الموافقة الصريحة مطلوبة.

رابعًا: الموافقة الصريحة وعرض السعر

عندما يكون قبول عرض السعر موجهًا لتكوين التزام تعاقدي، يجب أن يتمكن الطرف الموجه إليه، قبل إصدار الموافقة الصريحة، من مراجعة عرض السعر وجميع الشروط والمستندات التعاقدية التي ستدخل في الالتزام وفق المسار المعتمد، بما في ذلك مسودة العقد عندما تكون مستخدمة.

ويجب أن ترتبط الموافقة بالنسخة المحددة من عرض السعر وبكل مستند أو مجموعة شروط تعاقدية يتطلب المسار المعتمد موافقة المستخدم عليها. وعند استخدام مسودة عقد مستقلة، يجب أن تشمل رابطة الموافقة نسختها المحددة أيضًا.

ولا يُشترط وجود مسودة عقد مستقلة في كل معاملة، شريطة إتاحة جميع الشروط الجوهرية قبل الموافقة وتوثيق المستندات والنسخ التي شملتها الموافقة.

التي عُرضت على المستخدم وقت القبول.

ولا يجوز اعتبار الضغط على زر «قبول عرض السعر» موافقة على شروط جوهرية ظهرت لاحقًا ولم تكن متاحة للمستخدم عند اتخاذ القرار.

خامسًا: الموافقة الصريحة ومسودة العقد

لا تُعد مسودة العقد مقبولة قبولًا نهائيًا لمجرد عرضها أو فتحها أو تنزيلها أو قراءتها.

ويجب أن تتم الموافقة على النسخة المحددة من المسودة من خلال الآلية المعتمدة.

وعندما يطلب أحد الأطراف تعديلًا جوهريًا على المسودة، فلا تمتد موافقته السابقة تلقائيًا إلى النسخة المعدلة.

ويجب الحصول على موافقة جديدة عندما يكون التعديل من النوع الذي يتطلب قبولًا جديدًا.

سادسًا: الموافقة الصريحة وتكوين العقد

يجوز أن تكون الموافقة الصريحة الحدث أو أحد الأحداث التي يترتب عليها تكوين العقد، بحسب آلية التعاقد المعتمدة.

ويجب أن يكون النظام قادرًا على تحديد:

من وافق → على ماذا وافق → أي نسخة وافق عليها → متى وافق → بأي وسيلة → وما الأثر الذي ترتب على الموافقة.

ولا يجوز تكوين عقد ملزم استنادًا إلى استنتاج احتمالي عن نية المستخدم أو إلى تحليل تلقائي للمحادثة دون الموافقة المطلوبة.

سابعًا: الموافقة الصريحة والتعديلات

عندما يُقترح تعديل جوهري على عقد قائم، يجب الحصول على موافقة الطرف أو الأطراف المتأثرة عندما تكون موافقتهم مطلوبة.

وقد تشمل التعديلات الجوهرية:

1. السعر.
2. نطاق العمل.
3. المخرجات.
4. المراحل.
5. المواعيد.
6. حقوق الملكية الفكرية.
7. حقوق إعادة البيع أو إعادة الترخيص.
8. شروط التسليم أو القبول.
9. شروط الإلغاء أو الإنهاء.
10. أي التزام جوهري آخر.

ولا يجوز اعتبار تحديث تشغيلي بسيط تعديلًا تعاقديًا إذا لم يؤثر في الحقوق أو الالتزامات الجوهرية، كما لا يجوز استخدام وصف «تحديث تشغيلي» للتحايل على تعديل يتطلب موافقة.

ثامنًا: الموافقة الصريحة والتوقيع الإلكتروني

قد تُوثق الموافقة الصريحة من خلال توقيع إلكتروني أو إجراء إلكتروني موثق وفق طبيعة الإجراء والقانون واجب التطبيق.

ولا يعني كل إجراء موافقة صريحة أنه بالضرورة توقيع إلكتروني بالمعنى القانوني نفسه، كما لا يعني كل توقيع إلكتروني أن جميع الشروط المرتبطة بالمستخدم قد تم قبولها ما لم يكن نطاق التوقيع واضحًا.

ويجب تحديد العلاقة بين:

الموافقة ← المستند ← النسخة ← التوقيع أو وسيلة التوثيق.

تاسعًا: توثيق الموافقة

يجب أن تسمح المنظومة، بالقدر المناسب والمشروع، بحفظ سجل الموافقة الذي قد يتضمن:

1. معرف المستخدم أو الحساب.
2. صفة الشخص الذي أصدر الموافقة.
3. الجهة التي يمثلها، إن وجدت.
4. المستند أو الإجراء محل الموافقة.
5. معرف المستند.
6. رقم الإصدار.
7. تاريخ ووقت الموافقة.
8. وسيلة الموافقة.
9. معرف المعاملة أو العقد المرتبط.
10. أي بيانات تقنية لازمة ومتناسبة لإثبات سلامة الإجراء.

ويجب حماية سجل الموافقة من التعديل غير المصرح به.

عاشرًا: الموافقة الصريحة للأشخاص الاعتباريين والمؤسسات

عندما يكون المستخدم شركة أو جمعية أو جامعة أو جهة حكومية أو شبه حكومية أو أي شخص اعتباري، يجب أن تصدر الموافقة من شخص يملك الصلاحية اللازمة للتصرف نيابة عنها.

ولا يؤدي امتلاك المستخدم حسابًا تابعًا للجهة إلى منحه تلقائيًا صلاحية الموافقة على جميع العقود أو الإجراءات.

ويجب، بحسب الحاجة، التمييز بين صلاحيات:

إدارة الحساب ← طلب عرض السعر ← مراجعة العقد ← اعتماد العقد ← التوقيع ← اعتماد التعديل ← الإجراء المالي ← إدارة النزاع.

الحادي عشر: الموافقة الصريحة والإجراءات المالية

يجب الفصل بين الموافقة التعاقدية داخل بال لانسر وبين الموافقة أو التفويض المالي لدى الجهة المالية المرخصة.

ولا يعني قبول العقد أو عرض السعر أن المستخدم منح بال لانسر تفويضًا مفتوحًا لسحب أو حفظ أو تحويل الأموال.

وعندما يتطلب الإجراء المالي موافقة أو تفويضًا مستقلًا، يجب الحصول عليه وفق آليات البنك أو مقدم خدمات الدفع أو الجهة المالية المرخصة والقانون واجب التطبيق.

ويجب المحافظة على الفصل بين:

الموافقة على العقد → نشوء الالتزام التعاقدي → التفويض المالي → تنفيذ العملية المالية.

الثاني عشر: الموافقة الصريحة والمنتجات الرقمية

عندما تتعلق المعاملة بمنتج رقمي أو برنامج أو Source Code أو ترخيص، يجب أن يكون نطاق الحقوق التي يوافق عليها المستخدم واضحًا.

ويجب التمييز، بحسب الحالة، بين الموافقة على:

شراء نسخة ← حق استخدام ← ترخيص ← Source Code ← التعديل ← التوزيع ← إعادة البيع ← إعادة الترخيص ← White-Label ← نقل الحقوق الاقتصادية أو الفكرية.

ولا يجوز تفسير الموافقة على شراء المنتج باعتبارها موافقة تلقائية على نقل أو اكتساب حقوق أخرى لم يتم عرضها بوضوح.

الثالث عشر: الموافقة الصريحة والاشتراكات وSaaS

عندما تتعلق الموافقة باشتراك أو SaaS، يجب عرض العناصر الجوهرية المتعلقة بالاشتراك قبل الموافقة، بما في ذلك، بحسب الحاجة:

1. السعر.
2. دورية الاستحقاق.
3. مدة الاشتراك.
4. التجديد.
5. ما إذا كان التجديد تلقائيًا.
6. شروط الإلغاء أو عدم التجديد.
7. نطاق الاستخدام.
8. القيود الجوهرية.

ولا يجوز استخدام تصميم مضلل لإخفاء التجديد التلقائي أو المقابل الدوري متى كان الإفصاح عنه مطلوبًا.

الرابع عشر: الموافقة الصريحة والاعتماد التلقائي بعد مهلة

يجوز، عندما يسمح القانون والعقد وطبيعة المعاملة، استخدام آلية إجرائية محددة مسبقًا يترتب عليها أثر بعد انتهاء مهلة معلنة، مثل بعض حالات مراجعة التسليم.

ويجب ألا تُعامل هذه الآلية باعتبارها «موافقة صريحة» بالمعنى ذاته إذا كان الأثر قائمًا على قاعدة إجرائية سبق الاتفاق عليها، وإنما يجب توثيقها كحدث مستقل مثل:

انتهاء مهلة المراجعة وفق الشرط المتفق عليه.

ويجب أن تكون المهلة والنتيجة المترتبة على انتهائها واضحة للمستخدم عند موافقته على العقد الذي يتضمن هذه الآلية.

وهذا لا يجوز استخدامه لإنشاء عقد جديد أو إضافة التزام جوهري جديد دون موافقة مطلوبة.

الخامس عشر: الموافقة الصريحة والذكاء الاصطناعي

يجوز للذكاء الاصطناعي:

1. تحديد العناصر التي تحتاج إلى موافقة.
2. تنبيه المستخدم إلى نقص أو تعارض.
3. تلخيص المستند قبل عرضه.
4. المساعدة في توضيح آثار الإجراء.
5. توجيه المستخدم إلى المواضع التي تحتاج إلى مراجعة.

ولا يجوز للذكاء الاصطناعي:

إصدار الموافقة نيابة عن المستخدم ← افتراض الموافقة ← الضغط أو التنفيذ نيابة عنه ← تحويل السكوت إلى قبول ← إنشاء توقيع ← إنشاء التزام جوهري بناءً على استنتاج عن النية.

ويجب أن يظل الحدث الذي يرتب الأثر الملزم صادرًا من المستخدم أو الشخص المخول وفق الآلية المعتمدة.

السادس عشر: منع أنماط الموافقة المضللة

يجب ألا تُصمم واجهات الموافقة بصورة تهدف إلى تضليل المستخدم أو دفعه إلى قبول أمر لم يكن يقصده بصورة معقولة.

وبصفة خاصة، يجب تجنب:

1. إخفاء زر الرفض بصورة غير معقولة.
2. جعل خيار القبول بارزًا بصورة مضللة مقابل إخفاء البديل.
3. استخدام عبارات مبهمة لا توضح الأثر الحقيقي.
4. دمج عدة موافقات مختلفة في إجراء واحد عندما يلزم الفصل بينها.
5. إخفاء شرط جوهري وراء مسار غير واضح.
6. تغيير معنى الإجراء بعد تنفيذه.

ولا يمنع ذلك المنظومة من اشتراط موافقة على شروط مشروعة ولازمة لاستخدام خدمة معينة، متى كانت واضحة ومتوافقة مع القانون.

السابع عشر: الموافقة المجمعة والموافقات المنفصلة

يجوز جمع عدة شروط أو وثائق في موافقة واحدة عندما تكون مترابطة بصورة معقولة ويكون نطاق الموافقة واضحًا.

ولكن عندما تكون هناك موافقات ذات طبيعة مختلفة أو تتطلب القانون فصلها، يجب توفير موافقات مستقلة.

وبصفة خاصة، ينبغي عدم دمج دون ضرورة بين:

قبول العقد ← الموافقة على استخدام بيانات لغرض اختياري ← الاشتراك في التسويق ← التفويض المالي.

الثامن عشر: سحب الموافقة

عندما يكون نوع الموافقة قابلاً للسحب وفق القانون أو طبيعتها، يجب توفير وسيلة مناسبة لسحبها.

ولا يؤدي سحب الموافقة بذاته إلى إلغاء الآثار التي نشأت بصورة صحيحة قبل السحب.

كما لا يجوز استخدام مفهوم سحب الموافقة لإلغاء عقد قائم أو التهرب من التزام تعاقدي صحيح إذا كان إنهاء ذلك الالتزام يخضع لقواعد الإلغاء أو الانسحاب أو الإنهاء.

ويجب التمييز بين:

سحب موافقة قابلة للسحب ← إلغاء عقد ← الانسحاب ← الإنهاء.

التاسع عشر: انتهاء صلاحية الموافقة

قد تكون بعض الموافقات مرتبطة بحدث أو مستند أو مدة معينة ولا تستمر إلى ما لا نهاية.

ولا يجوز استخدام موافقة قديمة على نسخة أو غرض مختلف كأساس لإجراء جديد عندما تكون موافقة جديدة لازمة.

ويجب، بحسب الحالة، إعادة طلب الموافقة عند:

1. تغيير جوهري في المستند.
2. تغيير الغرض.
3. تغير صفة المستخدم.
4. انتهاء صلاحية التفويض.
5. وجود متطلب قانوني أو تعاقدي جديد.

العشرون: إثبات الموافقة في النزاع

يجوز استخدام سجل الموافقة كدليل على أن مستخدمًا أو شخصًا مخولًا أصدر إجراءً معينًا تجاه مستند أو نسخة محددة.

ويجب تقييم السجل مع بقية الأدلة، بما في ذلك:

الهوية، الصلاحية، المستند، النسخة، التوقيت، سجل النظام، وأي ادعاء بوجود خلل أو استخدام غير مصرح به.

ولا يعني وجود حدث تقني مسجل أن الموافقة صحيحة قانونًا في جميع الأحوال إذا ثبت مثلًا غياب الصلاحية أو وجود خلل جوهري في آلية الموافقة.

الحادي والعشرون: الموافقة والنسخ والإصدارات

يجب ربط كل موافقة بالنسخة المحددة من المستند الذي وافق عليه المستخدم.

وعندما يصدر مستند بإصدار جديد بعد تعديل جوهري، لا يجوز نقل الموافقة السابقة إليه تلقائيًا.

ويجب أن يسمح النظام بتحديد:

Document ID → Version → Consent Record → User → Date & Time.

وهذا الربط جزء أساسي من سجل التدقيق والإثبات في المنظومة.

الثاني والعشرون: العلاقة مع التعاريف الأخرى

يُقرأ تعريف «الموافقة الصريحة» بالاقتران مع:

تعريف المعاملة، أطراف المعاملة، مقدم الخدمة أو البائع، المشتري أو طالب الخدمة، عرض السعر، مسودة العقد، العقد، التوقيع الإلكتروني، التعديل، التسليم، القبول والرفض، الإلغاء، الانسحاب، الإنهاء، الجهة المالية المرخصة، مقدم خدمات الدفع، العملية المالية والاستحقاق المالي.

وعند وجود متطلب موافقة أكثر تشددًا في قانون أو عقد أو سياسة متخصصة، يُطبق المتطلب الأكثر ملاءمة والواجب قانونًا في نطاقه، ولا يجوز استخدام هذا التعريف لتقليل متطلب إلزامي أعلى.

Explicit Consent Definition

Status: Core Definition and Standard

Classification: Definitions & Standards — Contracting and Consents

Scope: All approvals, acknowledgements, and electronic acceptances issued by users within the PalLancer ecosystem that produce a contractual, legal, operational, or financial effect requiring the user’s consent under applicable law, the Contract, or approved policies.

First: Definition

For the purposes of the PalLancer ecosystem, “Explicit Consent” means a clear, affirmative, and documentable expression of the user’s intention to accept a specific action, document, term, or obligation, after the material information necessary to understand the nature of what is being accepted and its principal effects has been made available.

Explicit Consent must relate to a specific subject matter and be attributable to the person, account, or duly authorized representative who provided it.

Silence, failure to respond, or mere continued use of the ecosystem shall not, by itself, constitute Explicit Consent to form a Contract, materially amend an obligation, accept a Quotation, transfer a right, or issue a Financial Authorization, unless applicable law or the Contract permits a predefined procedural mechanism satisfying other lawful requirements consistent with this Definition.

Second: Core Elements of Explicit Consent

For consent to be treated as Explicit Consent within PalLancer, the following elements must, depending on the nature of the action, be satisfied:

1. It is given by the user or by a representative possessing valid authority.
2. It relates to a specific action, document, or obligation.
3. It is preceded by access to the material information and terms relating to the matter being accepted.
4. It is expressed through a clear affirmative action demonstrating the user’s intention.
5. It is capable of being documented and evidenced.
6. It is linked to the specific version of the document or term being accepted.
7. It is not obtained through misleading design or deliberate concealment of material information.
8. It is given within the appropriate context and authority of the person issuing it.

The mere existence of a document or term within the ecosystem shall not be sufficient to establish the user’s acceptance of it.

Third: Affirmative Action

Explicit Consent must involve an affirmative action by the user proportionate to the significance of the relevant commitment.

Depending on the circumstances, this may include:

1. Clicking a clearly identified acceptance button.
2. Selecting a checkbox that is not pre-selected.
3. Applying an Electronic Signature.
4. Entering a verification or confirmation code.
5. Approving a specified document or version.
6. Any other electronic action that appropriately evidences the user’s intention.

A pre-selected checkbox or interface design that makes rejection or non-consent unreasonably unclear shall not be used where Explicit Consent is required.

Fourth: Explicit Consent and the Quotation

Where acceptance of a Quotation is intended to create a contractual obligation, the recipient must, before providing Explicit Consent, be able to review the Quotation and all contractual terms and documents that will form part of the obligation under the approved workflow, including the Draft Contract where one is used.

Consent must be linked to the specific version of the Quotation and to each contractual document or set of terms requiring the user’s consent under the approved workflow. Where a separate Draft Contract is used, the consent linkage must also identify its specific version.

A separate Draft Contract is not mandatory for every Transaction, provided that all material terms are made available before consent and the documents and versions covered by the consent are documented.

Clicking an “Accept Quotation” button shall not constitute consent to material terms introduced later and not made available to the user at the time of acceptance.

Fifth: Explicit Consent and the Draft Contract

A Draft Contract shall not be deemed finally accepted merely because it has been displayed, opened, downloaded, or read.

Consent must be given to the specific version of the Draft Contract through the approved mechanism.

Where a party requests a material amendment to the Draft Contract, any prior consent shall not automatically extend to the amended version.

New consent must be obtained where the amendment is of a type requiring renewed approval.

Sixth: Explicit Consent and Contract Formation

Explicit Consent may constitute the event, or one of the events, resulting in Contract formation, depending on the approved contracting mechanism.

The system must be capable of identifying:

Who Consented → What Was Accepted → Which Version Was Accepted → When Consent Was Given → By What Method → What Effect Resulted from the Consent.

A binding Contract shall not be formed on the basis of a probabilistic inference concerning the user’s intention or an automated analysis of a conversation without the required consent.

Seventh: Explicit Consent and Amendments

Where a material amendment to an existing Contract is proposed, the consent of the affected party or parties must be obtained where such consent is required.

Material amendments may include changes to:

1. Price.
2. Scope of Work.
3. Deliverables.
4. Milestones.
5. Deadlines.
6. Intellectual Property rights.
7. Resale or relicensing rights.
8. Delivery or Acceptance terms.
9. Cancellation or Termination terms.
10. Any other material obligation.

A minor operational update shall not be treated as a contractual amendment where it does not affect material rights or obligations. Conversely, the description “operational update” shall not be used to circumvent an amendment requiring consent.

Eighth: Explicit Consent and Electronic Signature

Explicit Consent may be documented through an Electronic Signature or another documented electronic action, depending on the nature of the action and applicable law.

Not every act of Explicit Consent necessarily constitutes an Electronic Signature in the same legal sense, and an Electronic Signature shall not necessarily mean that every term associated with the user has been accepted unless the scope of the signature is clear.

The relationship between the following must be identifiable:

Consent ← Document ← Version ← Signature or Documentation Method.

Ninth: Documentation of Consent

To the appropriate and lawful extent, the ecosystem must enable retention of a Consent Record that may include:

1. User or account identifier.
2. Capacity of the person providing consent.
3. Entity represented, where applicable.
4. Document or action to which consent relates.
5. Document identifier.
6. Version number.
7. Date and time of consent.
8. Method of consent.
9. Associated Transaction or Contract identifier.
10. Any technical data that is necessary and proportionate to evidence the integrity of the action.

The Consent Record must be protected against unauthorized alteration.

Tenth: Explicit Consent for Legal Persons and Institutions

Where the user is a company, association, university, governmental or quasi-governmental entity, or another legal person, consent must be provided by a person possessing the necessary authority to act on its behalf.

The fact that a user has an account associated with an entity shall not automatically grant that user authority to approve all Contracts or actions.

Where appropriate, a distinction must be maintained between authority to:

Manage the Account ← Request a Quotation ← Review the Contract ← Approve the Contract ← Sign ← Approve an Amendment ← Perform a Financial Action ← Manage a Dispute.

Eleventh: Explicit Consent and Financial Procedures

A clear distinction must be maintained between contractual consent within PalLancer and financial consent or authorization provided to the Licensed Financial Entity.

Acceptance of a Contract or Quotation shall not mean that the user has granted PalLancer open-ended authority to withdraw, hold, safeguard, or transfer funds.

Where a Financial Procedure requires separate consent or authorization, it must be obtained through the mechanisms of the bank, Payment Service Provider, or other Licensed Financial Entity and in accordance with applicable law.

A clear separation must be maintained between:

Consent to the Contract → Creation of the Contractual Obligation → Financial Authorization → Execution of the Financial Transaction.

Twelfth: Explicit Consent and Digital Products

Where the Transaction relates to a Digital Product, software, Source Code, or license, the scope of the rights being accepted by the user must be clear.

Depending on the circumstances, a distinction must be maintained between consent to:

Purchase of a Copy ← Right of Use ← License ← Source Code ← Modification ← Distribution ← Resale ← Relicensing ← White-Label Rights ← Transfer of Economic or Intellectual Property Rights.

Consent to purchase the product shall not automatically be interpreted as consent to the transfer or acquisition of other rights that were not clearly presented.

Thirteenth: Explicit Consent, Subscriptions, and SaaS

Where consent relates to a subscription or SaaS, the material subscription terms must be presented before consent is given, including, where applicable:

1. Price.
2. Billing frequency.
3. Subscription term.
4. Renewal.
5. Whether renewal is automatic.
6. Cancellation or non-renewal conditions.
7. Scope of use.
8. Material restrictions.

A misleading design shall not be used to conceal automatic renewal or recurring charges where disclosure is required.

Fourteenth: Explicit Consent and Automatic Approval Following a Time Limit

Where permitted by law, the Contract, and the nature of the Transaction, a predefined procedural mechanism may produce an effect upon expiry of a disclosed time period, such as in certain Delivery review situations.

Such a mechanism should not be treated as “Explicit Consent” in the same sense where the effect arises from a previously agreed procedural rule. Instead, it must be documented as a separate event, such as:

Expiry of Review Period Pursuant to the Agreed Term.

The applicable period and the consequence of its expiry must be clearly disclosed to the user at the time the user consents to the Contract containing that mechanism.

Such a mechanism may not be used to create a new Contract or impose a new material obligation without the required consent.

Fifteenth: Explicit Consent and Artificial Intelligence

Artificial Intelligence may:

1. Identify elements requiring consent.
2. Alert the user to missing or conflicting information.
3. Summarize a document before it is presented.
4. Assist in explaining the effect of an action.
5. Direct the user to provisions requiring review.

Artificial Intelligence shall not:

Provide Consent on Behalf of the User ← Presume Consent ← Execute the Consent Action on the User’s Behalf ← Convert Silence into Acceptance ← Create a Signature ← Create a Material Obligation Based on an Inference of Intent.

The event producing the binding effect must remain attributable to the user or duly authorized person through the approved mechanism.

Sixteenth: Prohibition of Misleading Consent Patterns

Consent interfaces must not be designed to mislead users or induce them to accept something they did not reasonably intend to accept.

In particular, the following should be avoided:

1. Unreasonably concealing the rejection option.
2. Presenting the acceptance option in a misleadingly prominent manner while obscuring the alternative.
3. Using ambiguous wording that fails to explain the actual effect.
4. Combining multiple distinct consents into a single action where separate consent is required.
5. Concealing a material term behind an unclear process.
6. Altering the meaning of an action after it has been performed.

This shall not prevent the ecosystem from requiring acceptance of lawful and necessary terms for use of a particular Service where such terms are clear and legally compliant.

Seventeenth: Bundled and Separate Consents

Multiple terms or documents may be included within a single consent where they are reasonably related and the scope of the consent is clear.

However, where consents are of different legal nature or applicable law requires separation, separate consents must be provided.

In particular, the following should not be unnecessarily combined:

Contract Acceptance ← Consent to Optional Data Use ← Marketing Subscription ← Financial Authorization.

Eighteenth: Withdrawal of Consent

Where a particular type of consent may be withdrawn under applicable law or by its nature, an appropriate mechanism for withdrawal must be provided.

Withdrawal of consent shall not, by itself, invalidate effects that validly arose before withdrawal.

Nor may the concept of withdrawal of consent be used to cancel an existing Contract or avoid a valid contractual obligation where termination of that obligation is governed by Cancellation, Withdrawal, or Termination rules.

A distinction must be maintained between:

Withdrawal of Revocable Consent ← Contract Cancellation ← Withdrawal ← Termination.

Nineteenth: Expiry of Consent

Certain consents may relate to a specific event, document, or period and may not continue indefinitely.

An old consent relating to a different version or purpose may not be used as the basis for a new action where renewed consent is required.

Depending on the circumstances, renewed consent may be required where there is:

1. A material change to the document.
2. A change in purpose.
3. A change in the user’s capacity.
4. Expiration of authority.
5. A new legal or contractual requirement.

Twentieth: Evidence of Consent in a Dispute

A Consent Record may be used as evidence that a user or authorized person performed a specific action in relation to a specified document or version.

The record must be assessed together with other relevant evidence, including:

Identity, Authority, Document, Version, Timing, System Records, and any Allegation of a Defect or Unauthorized Use.

The existence of a recorded technical event shall not necessarily mean that consent is legally valid in every circumstance where, for example, lack of authority or a material defect in the consent mechanism is established.

Twenty-First: Consent, Versions, and Releases

Each Consent must be linked to the specific version of the document accepted by the user.

Where a new version of a document is issued following a material amendment, prior consent shall not automatically transfer to that version.

The system must be capable of identifying:

Document ID → Version → Consent Record → User → Date & Time.

This linkage forms an essential part of the ecosystem’s audit and evidentiary record.

Twenty-Second: Relationship with Other Definitions

The definition of “Explicit Consent” shall be read in conjunction with the definitions of:

Transaction, Transaction Parties, Service Provider or Seller, Buyer or Service Requester, Quotation, Draft Contract, Contract, Electronic Signature, Amendment, Delivery, Acceptance and Rejection, Cancellation, Withdrawal, Termination, Licensed Financial Entity, Payment Service Provider, Financial Transaction, and Financial Entitlement.

Where a stricter consent requirement applies under law, Contract, or a specialized policy, the legally applicable and more appropriate requirement shall apply within its scope. This Definition may not be used to reduce a higher mandatory consent requirement.